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

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

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

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

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

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

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

学习设计模式最有效的办法就是&＃xff1a;主动学习&＃43;刻意练习。

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

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

是不是还有以下疑惑&＃xff1f;

• 在面试中时常被问到设计模式&＃xff0c;可实际工作中却很少使用&＃xff1b;

• 每个模式的样例代码都很熟悉&＃xff0c;实际编码时却总感觉力不从心&＃xff0c;实现困难&＃xff1b;

• 很多系统设计看上去和很多模式都很像&＃xff0c;却不知道到底该用一个模式&＃xff0c;还是多个模式&＃xff1b;

• 设计模式除了在编码阶段有用外&＃xff0c;在设计上似乎用处并不大。

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

对设计模式常见的误解

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

因此&＃xff0c;要想学好设计模式&＃xff0c;就得摘去这些误解。

误解一&＃xff1a;经典模式太抽象&＃xff0c;很难学下去

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

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

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

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

误解二&＃xff1a;设计模式太单一&＃xff0c;复杂业务场景难落地

现在&＃xff0c;对于设计模式&＃xff0c;有两个非常有意思的现象

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

2. 在工作实践中&＃xff0c;绝大部分开发人员在项目中又找不到合适的应用场景。

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

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

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

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

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

误解三&＃xff1a;模式既然很好用&＃xff0c;那么一切皆模式

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

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

如何正确学习设计模式

• 首先&＃xff0c;要摆正心态。

  
  

  
  

  设计模式不是万能灵药&＃xff0c;不是银弹&＃xff0c;设计模式能解决的问题其实是有限的&＃xff0c;你应该始终保持一个平常的心态&＃xff0c;正确分析设计模式可以解决和不能解决的问题。

  
  

• 其次&＃xff0c;搞清楚设计模式的背景知识

  
  

  
  

  比如&＃xff0c;设计模式如何定义&＃xff1f;设计模式的历史演进与变化&＃xff1f;设计模式有哪些适用的领域&＃xff1f;又有哪些不适用的领域&＃xff1f;如何结合实践分析和使用&＃xff1f;

  
  

  
  

  
  

  学习一门知识时&＃xff0c;如果总是忽略关联的背景知识&＃xff0c;久而久之会养成零碎知识积累的习惯——收藏了很多资料&＃xff0c;拆解、吸收却很少。而在学习关联知识时&＃xff0c;你会发现&＃xff0c;原来的知识会逐渐连接和串联起来&＃xff0c;这是一个事半功倍的动作。

  
  

• 再次&＃xff0c;努力具备高手独立思考的习惯

  
  

  
  

  互联网时代&＃xff0c;不缺资料和方法&＃xff0c;缺的是能解决复杂难题的高手。高手之所以成为高手&＃xff0c;是因为高手不拘泥于某一知识的高低贵贱&＃xff0c;而是保持明智的判断&＃xff0c;始终朝着坚定的目标前行。