深入理解设计模式（终）：总结--设计模式是药，没病就不要吃药

系列链接地址：

一、产品汪的神助攻，代码狗的安慰剂

定义：设计模式，指的是一个场景(context)下的一种解决方法（solution），只要大家都认可某种模式，那么就只需要很短的一个名字，就可以代替很多很多的语言和文字交流，如果你觉得设计模式降低生产效率，那只能说你在这一行还要继续修炼。

宗旨：保证系统的低耦合高内聚，指导它们的原则无非就是封装变化，责任单一，面向接口编程等设计原则

目的：就是为了让代码变得更容易理解和维护

精髓：将复杂的逻辑抽离出来，让开发人员真正专注于业务代码，系统，那么设计模式会加大理解难度。但当你看懂之后，你会发现这么做真是太巧妙了！

 

设计模式无非就是把代码抽象出一个更高的层次，再来实现原先想要实现的功能，设计模式是有代价的，以复杂度换取灵活性，，说到底是为了给自己留条后路，在代码走向可能发生变化的点上留下灵活性的种子。

二、设计模式是黏合剂

我最初在学习设计模式的过程中由一种困惑，“这样继承封装多态乱七八糟的绕来绕去的干嘛？”后来慢慢的随着经验的积累才知道是迫不得已，这种迫不得已，有很多种原因。个人觉得最容易理解的就是“适配器模式”，因为出现了接口的冲突，所以我们不得不进行适配。但一个很自然的问题就是：为什么不直接改接口让他们自然融洽呢？这不是一种更自然更直观的解决方案吗？答案很有可能就是因为架构，大的架构已经确立，局部必须服从整体。

那么，如果一个完全理想化的架构，是不是根本就不应该出现这种问题接口冲突的问题，因而根本就不需要这种设计模式？

不是的，设计模式是黏合剂，它的作用是弥补架构的局部缺陷，更好的支撑架构。更极端的一种说法可以送给痴迷于设计模式的同学：设计模式是药，没病就不要吃药！

 

设计模式是为了封装变化，让各个模块可以独立变化。精准地使用设计模式的前提是你能够精准的预测需求变更的走向。我们都知道大部分人是做不到的，所以大部分人就算精通设计模式也多少会做错点什么东西。所以这其实不怪设计模式，怪产品狗</del>。所以说如何避免过度设计，这就要求你深入的理解你的程序所在的领域的知识，了解用户使用你的软件是为了解决什么问题，这样你预测用户的需求才会比以前更加准确，从而避免了你使用设计模式来封装一些根本不会发生的变化，也避免了你忽视了未来会发生的变化从而发现你使用的模式根本不能适应需求的新走向。

三、模式无处不在

要为实现需求而编码，而不是为使用设计模式而编码。象张无忌学太极一样，学会了，然后忘了，不要刻意使用设计模式，模式无处不在。

很多同学在学习设计模式的时候看到的只是结果，并不了解过程和动机，也就是其他人在什么样的情况下做出这样的设计，而这个恰恰是各种教程、资料上学习不到的。

在几年前我自己制定了类代码行数不超过600，函数行数不超过60，嵌套不超过3层的编码规则。这个规则非常明确，比“高内聚，低耦合”之类的可执行性高多了，我自己实践过程中，一旦违反这条规则的时候，就不断的重构至这个目标。

经过3，4年的实践，基本上做到了任何时候、场合都符合自己所制定的规则。现在阅读我写的代码的时候，往往能发现其中有些地方符合一些设计模式的地方。回过头思考设计模式的时候，悟出了开篇关于设计模式学习、应用的那个弊端。

四、脱离业务需求谈设计模式都是耍流氓

离开具体业务需求谈设计模式都是耍流氓,oop的世界里出现设计模式是为了让程序更有弹性,易于扩展。而且经过这么多年的发展,前辈们从具体的业务需求抽象出很多种的设计模式，设计模式，是为了需求变动而产生，抛开需求谈模式，显得很苍白。

没有完美的设计模式，它只适应于特别的场合，要理解和掌握设计模式，要从发现需求变动， 准确找到变化点，如何封装它的角度去研究，去学习，而不要拘泥于具体的形式。换句说话：在23种设计模式的需求中，要准确找出哪些地方是强耦合，并且由于实际需要，要对这些耦合进行解耦。这样才是真正的理解了设计模式。