设计模式只是一把锤子 | 文末赠书
Posted 架构头条
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了设计模式只是一把锤子 | 文末赠书相关的知识，希望对你有一定的参考价值。
然而，设计模式真的是软件设计的“瑞士军刀”，切、削、锯、钻样样精通吗？
读过《设计模式》的读者估计不少，但真正注意过《设计模式》的副标题的估计很少，而这个副标题却是避免误解设计模式的关键。《设计模式》的副标题是：可复用面向对象软件的基础！
不要小看了这短短的一句话，如果你没有看这句话，或者只是一扫而过并没有仔细体会，那么你很可能就认为设计模式是一把“瑞士军刀”，能够解决所有的设计问题；而实际上“设计模式只是一把锤子”，有句谚语叫作“如果你手里有一把锤子，那么所有的问题都变成了钉子”，如果你拿着设计模式这把锤子到处去敲，要么东西被敲坏，要么就不起作用。
为什么说设计模式只是一把锤子呢？我们还是从副标题来看。《设计模式》的副标题揭示了设计模式的两个主要约束。
设计模式解决的是“可复用”的设计问题；
设计模式应用的领域是“面向对象”。
相信经过我这么一提醒，大家基本上都能够明白了为什么说“设计模式只是一把锤子”了。
设计模式只能解决“可复用”的设计问题，其他的例如性能设计、可靠性设计、安全性设计、可服务性设计等都不是设计模式能够解决的；
设计模式只是在面向对象的语言中应用，如果是非面向对象的语言，那么就不怎么好用了。当然，你可以在 C 语言中应用设计模式，但毕竟要有不少折腾，用起来也不那么得心应手。
所以，当你遇到一个问题就想到设计模式的时候，一定要注意“设计模式只是一把锤子”，不要拿着这把锤子到处去敲！
形而上者谓之道，形而下者谓之器。—《易经·系辞》
正如很多流行的技术（面向对象、UML 等）一样，几乎大部分人都会宣称自己“掌握”“熟练掌握”，甚至“精通”，然而，真正掌握或者精通的人实在是少之又少。
一个典型的现象是：很多人能够熟练背诵出所有的设计模式，能够快速画出各种设计模式的 UML 类图，也能够熟练地写出《设计模式》一书中各个模式的样例代码。但一到实际的项目设计和开发的时候，往往都会陷入迷茫：要么无从下手，不知道哪个地方要用设计模式；要么生搬硬套，胡乱使用设计模式，将方案和代码搞得一团乱麻。
这是什么原因呢？难道是设计模式不好用，或者设计模式根本就是一个噱头？
答案不在于设计模式本身是否有用，而是在于我们没有掌握正确的学习和应用设计模式的方法。
学习《设计模式》一书中的 23 个设计模式，只是掌握了设计模式的“器”，但并没有掌握设计模式的“道”。就像一个工匠，锯、钻、锤、刨样样精通，但如果不知道在什么地方该用锯，在什么地方该用钻，那么他肯定是一个不合格的工匠。为了能够更好地学习和应用设计模式，我们也需要掌握设计模式的“道”。
设计模式的“道”就是用来指导我们什么时候用设计模式，为什么要用设计模式，23 个设计模式只是告诉了我们 How，而设计模式之道却可以告诉我们 Why 和 Where！
熟悉《设计模式》一书内容的读者可能会想到：在《设计模式》中，不是每个模式都有“适用性”的说明吗？这个其实就是回答了 Where 和 Why 的问题啊！
例如，Facade 模式的“适用性”说明如下（摘自《设计模式》中文版）。
在遇到以下情况时使用 Facade 模式。
当你要为一个复杂子系统提供一个简单接口时，子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类，这使得子系统更具可重用性，也更容易对子系统进行定制。但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade 可以提供一个简单的默认视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过 Facade 层。
客户程序与抽象类的实现部分之间存在着很大的依赖性，引入 Facade 将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
当你需要构建一个层次结构的子系统时，使用 Facade 模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，则可以让它们仅通过 Facade 进行通信，从而简化了它们之间的依赖关系。
上面这段文字，看起来回答了 Where 和 Why 的问题，但实际上我个人感觉作用并不大。
首先，这段描述太长了：上面这段文字是否花了你几分钟的时间去阅读和理解？
其次，这段描述比较抽象：什么是复杂，什么叫作简单，什么叫作很大依赖性……可能每个人的理解都不一样。
最后，23 个模式，所有的“适应性”条款加起来估计有几十条，你能够记住吗？即使能够全部记住，你能够全部理解吗？即使能够全部理解，当你面对一个具体问题的时候，你知道几十条里面哪一条适应你的情况吗？
所以，《设计模式》一书中关于“适用性”的描述，实际上还是太复杂、太多了，不具备很强的实践指导意义和可操作性。
我们需要的是一个更简单的指导思想，“大道至简”，最好是一两句话就能够描述清楚！
幸运的是，答案竟然就在《设计模式》一书中，但这个答案并不是那么明显！
《设计模式》一书内容的侧重点是 23 个模式的详细阐述，大部分人可能都是直奔主题，逐一去研究每个模式，而对于本书开头部分第 1 章和第 2 章的内容并没有详细研读和思考，或者对于这两章只是简单地浏览，并未认真领会和思考，由此错过了最重要的内容。再加上 GoF 在这两章的内容中，既要引入一个全新的概念，又要提纲挈领地介绍各个模式，还要引入实例进行分析，以至于大量的内容反而将真正核心的内容给淹没或者冲淡了。
设计模式之道就隐藏在“2.6.2 封装实现依赖关系”的最后一段，很简单的一句话：
对变化的概念进行封装（encapsulate the concept that varies）。
你看到这句话可能有点失望，前面分析了那么久，卖了那么多的关子，结果就这么简简单单一句话，这不是在忽悠吗？
你可千万别小看了这句话，“大道至简”，设计模式之道也不例外，但“简”并不意味着没用；相反，正因为其“简”，每个人的理解才一致，也更好掌握，在实践中才更好应用。正所谓：“真传一句话，假传万卷书”。
GoF 在《设计模式》一书中最早提出这个原则，后来不断地有其他专家进行阐述，其中《设计模式精解》（Design Pattern Explained）一书的阐述我认为是最精辟的：Find what varies and encapsulate it。翻译一下即“找到变化，封装变化”。虽然含义和 GoF 描述的基本一致，但其更加容易理解。
正所谓：踏破铁鞋无觅处，得来全不费工夫！
现在，让我们来深入理解“找到变化，封装变化”的设计模式之道。
首先，“找到变化”解决了“在哪里”使用设计模式的问题，即回答了“where”的问题。
“找到变化”看起来是比较抽象的一句话，但在实践中非常好应用和操作，而且不同领域、不同行业的系统都可以完美地应用这句话。虽然不同领域、不同行业变化的因素、方式、时机等都不一样，但每个领域或者行业的需求分析人员、设计人员，对自己所处行业和领域的可能变化肯定是有比较深刻的理解的，什么会变化、会如何变化、什么时候会变化……肯定都能够自己判断，这种判断并不需要高深的技巧和知识水平，只需要一定的经验积累。
如果我们刚接触一个行业或者领域，经验积累不够，那么怎么办呢？是否就无法“找到变化”了？
其实也不然，有一个万能的办法，只是要花费更多的精力了。
这个万能的办法就是“唯一不变的是变化本身”，也就是说，如果你不知道什么会变化，那么就抱着怀疑一切的想法，一切都可能是变化的。
但光有这条指导原则还不行，如果我们真的抱着“一切都是可能变化的”的想法，然后封装一切变化，那么就会陷入变化的旋涡中无法自拔，因为变化是会递归的，A 可能变成 B，B 也可能继续变化，于是这样无穷无尽，系统是不可能做出来的。
所以我们需要一个终止条件，避免陷入无穷无尽的变化递归旋涡中。这个终止条件就是“有限时间内可能发生的变化”。这里的“有限时间”随行业和领域的不同而变化。例如（以下时间仅供参考）：
互联网行业可以说，半年内可能发生的变化……
电信行业可以说，1 年内可能发生的变化……
金融行业可以说，2 年内可能发生的变化……
政府行业可以说，3 年内可能发生的变化……
有了这个指导原则后，你可以这样去问有经验的前辈、“大牛”等：XXX 在 1 年内会发生变化吗？会怎样变化？
就这样，即使你是“菜鸟”，通过这么一招“借花献佛”，也能够轻松发现“变化”的地方。
其次，“封装变化”解决了“为什么”使用设计模式的问题，即回答了“Why”的问题。
为什么我们要用设计模式？是因为我们要封装变化！但我们为什么要封装变化呢？
答案很明显：变化不好！
当然这个“不好”不是从业务的角度来说的，而是从系统的角度来说的。从业务的角度来说，“变化”是好的，变化意味着新的机会；但从系统的角度来说，变化并不好，因为变化必然要求系统改动，改动就意味着风险！
虽然变化给系统带来风险，但我们不能因此而“拒绝变化”，因为拒绝变化就意味着失去了机会。简单来说，赚不到钱的系统，设计再优美，功能再强大，系统再稳定，也不过是一堆无用的摆设：
客户给你提了新需求，你不做，能拿到合同吗……
行业正在兴起新的流行功能，你不做，你的系统有人用吗……
一项创新带来了新的机遇，你不做，能抢占市场吗……
因此，我们要“拥抱变化”，但又不能让变化带来太大的风险，所以就提出了“封装变化”。“封装变化”意味着将变化的影响范围控制到最小，将风险降到最低。
我们来看看变化会带来哪些问题和风险。
开发人员需要编码以适应变化，设计不好的方案将导致大量的编码工作量、自测工作量；
测试人员不单要测试因变化而新增的部分，还要测试受影响的部分，设计不好的方案，牵一发而动全身，导致测试工作量大大增加；
如果为了适应某个变化而对系统做了比较大的改动，则系统的质量风险将上升，很可能导致上线失败，或者上线后出现各种问题。
因此，我们要尽量减少变化带来的工作量和风险，而减少的最有效方法就是将变化的影响范围缩小，即将变化封装起来，使其只在有限的范围内有影响。
就像一个武林高手有了深厚的内功，天下万物皆可成为手中的利器，而不必拘泥于具体的武器和招数一样，掌握了设计模式之道后，我们其实也完全可以不拘泥于只使用《设计模式》一书中的 23 个设计模式，可以根据需要选择最合适的方案。
例如：
不同的业务有不同的规则排列组合，规则引擎可以封装各种变化的规则……
类之间的依赖是变化的，Spring 使用 XML 配置文件来封装这种变化……
每个银行的卡都不一样，银联封装了这种变化，使得不同银行可以互通……
总之，你可以使用类和设计模式来封装变化，也可以使用配置文件和模块来封装变化，还可以使用一个系统来封装变化……
本文选自李运华老师新作《编程的逻辑：如何用面向对象方法实现复杂业务需求》，本书会通俗易懂地带你揭示面向对象的本质，助你实现复杂的业务需求！
面向对象基础：通过对面向对象相关的历史、发展、与面向过程的对比等相关背景知识的介绍，让读者对面向对象有一个更完整的认识；并深入的阐述了面向对象的各种概念，让读者“知其然并知其所以然”
面向对象方法：通过一个实例，完整的介绍面向对象相关技术如何在软件开发流程中落地，整个面向对象的开发流程一环扣一环，步步为营，让读者避免“拍脑袋”、“头脑风暴”式的开发方式
面向对象技巧：对“内聚耦合”、“设计模式”、“设计原则”、“UML”等最常见的面向对象技术进行了深入和别具一格的阐述，让读者不但知道“What”（是什么），还能知道“Why”（为什么）和“How”（如何用）
敲黑板！本次我们联合博文视点为大家准备了 5 本《编程的逻辑：如何用面向对象方法实现复杂业务需求》，拼手气的时候到了，谁才是锦鲤？
开奖时间：9 月 21 日 20:00
点个在看少个 bug 以上是关于设计模式只是一把锤子 | 文末赠书的主要内容，如果未能解决你的问题，请参考以下文章