设计模式 - 基本功的重要性

桃扇骨 2022-10-17 00:57 119阅读 0赞

### 文章目录 ###

*  基本功
 *  如何学好设计模式
 *   *  对设计模式常见的误解
     *   *  误解一：经典模式太抽象，很难学下去
         *  误解二：设计模式太单一，复杂业务场景难落地
         *  误解三：模式既然很好用，那么一切皆模式
     *  如何正确学习设计模式

![在这里插入图片描述][resize_m_lfit_w_962_pic_center]

--------------------

# 基本功 #

**代码质量既是设计出来的，也是迭代优化出来的**。换句话说，无论是前期的产品需求分析、架构设计，还是后期的详细代码设计与编码，都离不开良好的设计。

程序设计是每个程序员的基本功。但是，大多数人都只是对新技术充满热情，却很少有人愿意沉下心来，花几个月甚至一两年的时间来重温基础知识，修炼基本功。

在面对所谓“新技术”的浪潮下，一直看不透背后隐藏的朴实规律，只是东一榔头西一棒槌地在原地踏步。

![在这里插入图片描述][20210531225324881.jpg_pic_center]

当我真正亲身参与到编码实践和设计中后，才猛然发现设计模式的诸多优势，比如，提升源码阅读效率，快速解决短期项目中的问题，降低维护成本等。

而在不断学习与实践设计模式的过程中收获了很多实打实的经验，包括编程的技巧、架构设计的启发、面试技巧等

--------------------

# 如何学好设计模式 #

有了学习设计模式的目标之后，还得找对学习设计模式的正确方法。

学习设计模式最有效的办法就是：**主动学习+刻意练习**。

在实际工作中，很少有人告诉你一个程序该如何设计，他们只会要求有一个结果——做出一个好的程序并能运行起来。

面对这样的要求，你常常只能处于被动学习状态：任务里需要什么你才学习什么，东一榔头，西一棒槌。这样短期虽然有效，但是长期下来，你的知识积累速度其实很慢。所以，要想学好设计模式，你就得放**弃这种被动学习的方式，要有目标、有系统地去主动学习：找寻好的资料，分析理解，开放思维**。

是不是还有以下疑惑？

*  在面试中时常被问到设计模式，可实际工作中却很少使用；
 *  每个模式的样例代码都很熟悉，实际编码时却总感觉力不从心，实现困难；
 *  很多系统设计看上去和很多模式都很像，却不知道到底该用一个模式，还是多个模式；
 *  设计模式除了在编码阶段有用外，在设计上似乎用处并不大。

其实，当时这些困惑的关键**并不在于设计模式过于抽象或应用有难度，而在于我可能从一开始就没有搞清楚设计模式的应用范围和背景**：设计模式到底解决什么问题？为什么要抽象这样的场景？又是如何解决这些问题的？

![在这里插入图片描述][2021053122594648.jpg_pic_center]

## 对设计模式常见的误解 ##

正因为没有搞清楚这些应用范围和背景，才导致大多数时候我们总是在“生搬硬套”设计模式，以为在应用设计模式，却不知道还没入门就一直在误解设计模式，并无法控制地胡乱使用，最后反而引入了很多不必要的麻烦。

因此，要想学好设计模式，就得摘去这些误解。

### 误解一：经典模式太抽象，很难学下去 ###

> 说到设计模式，你的第一反应是不是会想起“四人帮”GoF 的那本“经典”著作《设计模式：可复用面向对象软件的基础》？或者想起那 23 个“经典”的模式？

> 的确，设计模式太过于经典了，但是经典也会带来一个问题：过于抽象，难以快速理解。而对于业余时间本就不多的你来说，读抽象的经典更是一件难上加难的事。

**简单来说，设计模式从不同项目中总结出来的通用经验，是为了帮助我们快速理解现有的系统，并从中找出共性规律，如果没有足够的经验或者思考，反而容易引入错误的设计，造成更多的麻烦。**

所以说，“经典太抽象”只是一个事实，只要你能肯花时间认真解读，学下去并不难。

--------------------

### 误解二：设计模式太单一，复杂业务场景难落地 ###

> 现在，对于设计模式，有两个非常有意思的现象

> 1.  在理论学习中，几乎所有的开发人员都认为它很重要。

> 1.  在工作实践中，绝大部分开发人员在项目中又找不到合适的应用场景。

其实，发生这个冲突的关键点在于：没有搞清楚设计模式解决问题的范围所在。换句话说，**设计模式并不是一种全场景的解决方案，它需要考虑适用范围。**

比如，在面向对象语言 Java 领域中，如何最大限度发挥面向对象语言的继承与组合的威力？如何解耦程序的相互依赖？设计模式会提供一些解答。

如果说你现在接到的是一个复杂系统的设计任务，比如，如何设计一个秒杀系统？你不仅需要关心业务功能的实现，还要关心不同开发成员间的相互配置、服务器资源等，而此时你的脑海中浮现设计模式中的适配器模式、策略模式、状态模式……对你来说帮助并不那么明显，因为你其实还没有到如此需要细节实现的阶段。

实际上，**设计模式的提出就是为了解决限定领域的有限问题**。 比如，针对非业务场景的技术框架，如何实现可复用的软件？如何能够为更多的人提高编程效率？像 Spring、Netty、MyBatis、JDK 等大家公认的工具，其实随处可见设计模式的应用，但同时并不是只有设计模式本身。

所以说，你不能把设计模式当作一种通用解决方案来对待，或者认为它就应该解决超出范围的问题，一定要考虑好它的适用范围，否则问题是得不到有效解决的。

--------------------

### 误解三：模式既然很好用，那么一切皆模式 ###

**好的设计从来不是看用的模式有多少，而是看如何合理利用模式的设计思想，以及如何利用模式解决真实的问题。**

所以说，学习设计模式是**为了启发我们的思考**，而**不是“手里握着锤子，满世界找钉子”**。

--------------------

## 如何正确学习设计模式 ##

*  首先，要摆正心态。
    
    > 设计模式不是万能灵药，不是银弹，设计模式能解决的问题其实是有限的，你应该始终保持一个平常的心态，正确分析设计模式可以解决和不能解决的问题。
 *  其次，搞清楚设计模式的背景知识
    
    > 比如，设计模式如何定义？设计模式的历史演进与变化？设计模式有哪些适用的领域？又有哪些不适用的领域？如何结合实践分析和使用？
    
    > 学习一门知识时，如果总是忽略关联的背景知识，久而久之会养成零碎知识积累的习惯——收藏了很多资料，拆解、吸收却很少。而在学习关联知识时，你会发现，原来的知识会逐渐连接和串联起来，这是一个事半功倍的动作。
 *  再次，努力具备高手独立思考的习惯
    
    > 互联网时代，不缺资料和方法，缺的是能解决复杂难题的高手。高手之所以成为高手，是因为高手不拘泥于某一知识的高低贵贱，而是保持明智的判断，始终朝着坚定的目标前行。

[resize_m_lfit_w_962_pic_center]: /images/20221014/80b1b16a2d81402d80f21f4dbd57a283.png
[20210531225324881.jpg_pic_center]: /images/20221014/89ad63a5341e4a7fa0b29fac7fb1d9ee.png
[2021053122594648.jpg_pic_center]: /images/20221014/eb2c2d03246c4cbd8cf5e533c90bf394.png