设计模式 概述

设计模式（Design Pattern）代表了最佳实践，通常是软件开发人员在开发中面临的一般问题的解决方案，这些解决方案是众多软件开发人员经过相当长一段时间的试错后总结出来的。任何被广泛使用的技术或者功能都会有特定的经验总结，因此面向对象有面向对象的设计模式，软件架构有软件架构的设计模式，数据口有数据库的设计模式。对于转发类型的芯片，其软件架构有一定的设计模式，同时可编程的微码也存在一定的设计模式与设计原则。当然，我们常说的设计模式默认情况下指的是面向对象设计模式。

对于那些具有丰富的开发经验的开发人员，学习设计模式有助于了解在软件开发过程中所面临的问题的最佳解决方案；对于那些经验不足的开发人员，学习设计模式有助于通过一种简单快捷的方式来学习软件设计。通过这个专题期望能够掌握高内聚/松耦合设计思想、面向对象的设计原则、GOF核心设计模式、重构技法改善设计。

1. 设计模式概念

模式：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。设计模式为什么被广泛使用，主要两个方面的原因。第一个原因是设计模式经历了很长时间的发展，他们提供了软甲开发过程中面临的一般问题的解决方案。学习这些设计模式有助于经验不足的开发者通过一种简单快捷的方式来学习软件设计。另外座椅统一的术语系统，具有特定的情景。

在进行代码编程过程中我们首先会学习到语言的底层思维，这些思维主要包含语言的基本语法、编译方式、内存管理、生死周期、运行机制和一些数据结构和算法。这些基本知识能够让我们更好的理解和把握语言的特性，和语言组织方式方法，学会了基本的造句。但是再解决实际问题过程中，工程问题的复杂性需要我们在更高维度具备面向对象、组件分装、设计模式、架构模式等抽象归类的思维方式。

1.1. 设计模式起因

为什么会出现设计模式内容。人类在处理变化复杂的问题时，常常会通过抽象隔离出核心的维度将事物模型化，进而通过数学的方式来描述和实现研究管理这些事物。同时，另外一个维度一种重要的方式是分解，分而治之。分解在实际代码编程中长被if else或者Switch case这样的语句包含，这种处理方式对于较小工程较少代码很实用，修改难度不大。但是很多时候这种情况是再工程较大重复工作角度的情况下面维护较为困难，很多时候修改内容遍地开花，重复代码较大。因此，抽象的方法在这这种工程中往往后期重构当中一个重要的工作。所以，由上面的描述我们可以大概知道一般工程开始的时候分解法是最常被使用的软件编码方式。等待功能稳定或者出现更多问题的时候逐渐开始重构代码实现设计模式。当然，在软件行业当中，只有不断重构才能有能力的提升，否则不断的重复工程只会是原地不断踏步。

软件设计金科玉律：复用！

1.2. 面向对象设计模式

面向对象设计模式是一套反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码，让代码更加容易被他人理解、保证代码可靠性和可维护性。毫无疑问，设计模式于己于他于项目都是多赢的。设计模式是代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目合理的使用设计模式可以完美的解决很多问题，每种设计模式再实际中都有相应的原理与之对应，每种设计模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式被广泛应用的原因。面向对象的机制：封装、继承、多态。

面向对象时现代高级语言的一条重要的技术线，其核心主要包含对象、封装、继承和多态等基本思维方式。其中，对象和封装两个特性从语言层面来看，对象封装了代码和数据；从规格层面来讲，对象是一系列可被使用的公共接口；从概念层面讲，对象是某种拥有责任的抽象。各个对象各司其职，从宏观层面来看，面向对面个的方式更强调各个类的“责任”；由于需求变化导致的新增类型不应该影响原来类型的实现。面向对象继承与多态结合将不同类之间的三种核心关系充分体现出来，使得软件开发中的各种变化隔离，从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的的影响减为最小。两者结合威力体现需要开发人员具有极强的抽象能力。

1.3. GOF与设计模式

在1994年，有Erich gamma、Richard Helm、Ralph johnson和John vissides私人合著出版了一本名为Design patterns – Elements of Reusable Ogject-oriented software的书，该书首次提到了软件开发设计模式的概念。四人作者合称GOF。他们所提出的设计模式主要是基于两个面向对象的设计原则，分别是：对接口编程而不是对实现编程、优先使用对象组合而不是继承。

目前设计模式在Design Patterns中共包含23种。这些设计模式可以分三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。当然，我们还会讨论另外一种设计模式J2EE设计模式。

序号	模式 & 描述	包括
1	创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。	工厂模式（Factory Pattern） 抽象工厂模式（Abstract Factory Pattern） 单例模式（Singleton Pattern） 建造者模式（Builder Pattern） 原型模式（Prototype Pattern）
2	结构型模式 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。	适配器模式（Adapter Pattern） 桥接模式（Bridge Pattern） 过滤器模式（Filter、Criteria Pattern） 组合模式（Composite Pattern） 装饰器模式（Decorator Pattern） 外观模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern）
3	行为型模式 这些设计模式特别关注对象之间的通信。	责任链模式（Chain of Responsibility Pattern） 命令模式（Command Pattern） 解释器模式（Interpreter Pattern） 迭代器模式（Iterator Pattern） 中介者模式（Mediator Pattern） 备忘录模式（Memento Pattern） 观察者模式（Observer Pattern） 状态模式（State Pattern） 空对象模式（Null Object Pattern） 策略模式（Strategy Pattern） 模板模式（Template Pattern） 访问者模式（Visitor Pattern）
4	J2EE 模式 这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。	MVC 模式（MVC Pattern） 业务代表模式（Business Delegate Pattern） 组合实体模式（Composite Entity Pattern） 数据访问对象模式（Data Access Object Pattern） 前端控制器模式（Front Controller Pattern） 拦截过滤器模式（Intercepting Filter Pattern） 服务定位器模式（Service Locator Pattern） 传输对象模式（Transfer Object Pattern）

当然我们还可以从另外实现的角度来对设计模式进行一个划分。类模式处理类与子类的静态关系。对象模式处理对象间的动态关系。

从分装变化角度对模式分类，方便理解和打磨设计模式能力。

 2. 设计原则

接口标准化是一个产业强盛的标志，有很强大的一个团队在维护标准接口。接口把各个模块隔离开来，进而实现了高效的协作。设计模式是实际开发过程中经验总结，从这个角度来讲设计原则这些精华要比实际掌握哪个设计原则要重要。

1. 依赖倒置原则（DIP）：高层模块（稳定）不应该依赖于低层模块（变化），二者都应该依赖于抽象（稳定）；抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖抽象（稳定）。抽象提出是核心。具体内容：针对接口编程，依赖于抽象而不依赖于具体。
2. 开放封闭原则（open close principle，OCP）：对扩展开放，对更改封闭。类模块应该是可扩展的，但是不可修改。面对需求的变化不是漫天修改，二是增加一部分内容来实现。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
3. 单一职责原则（SRP）：一个类应该仅有一个引起它变化的原因；变化的方向隐含类的责任。一个类接口与行数是有限制的，避免太多功能把类拉扯到不同的方向。
4. Liskov替换原则（Liskov Substitution Principle，LSP）：子类必须能够替换他们的基类（IS-A）；继承表达类型抽象。所有需要父类的地方子类都是应该可以传过去使用。一个反例是很多时候写代码子类中发现父类几个方法不能使用，直接使用异常方式抛出，这就使用父类的地方，子类没有办法使用了，违背了替换原则。实际两个类关系更可能是一个并列关系。里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
5. 接口隔离原则（Interface Segregation Principle，ISP）：不应该强迫客户程序依赖他们不适用的方法；接口应该小而完备。接口要合理定义，同时接口内部实现函数的权限是明确区分下来的，是public、private都要明确定义。这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
6. 合成复用原则（Composite Reuse Principle）优先使用对象组合，而不是类继承：累积成通常为“白箱复用”，对象组合通常为“黑箱复用”；继承在某种程度上破坏了分装性，子类父类的耦合度高；二对象组合只要求被组合的对象具有良好的定义的接口，耦合度低。不要掉到固有的继承思维当中，合理使用面向对象的继承。尽量使用合成/聚合的方式，而不是使用继承。
7. 分装变化点：使用分装来创建对象之间的分界层，让设计者可以在分界层一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。
8. 针对接口编程，而不是针对实现编程：不讲变量类型的声明为某个特定的具体类，二是声明为某个接口；客户程序无需获知对象的具体类型，只需要知道对象所具有的接口；减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。和第一个依赖倒置原则是同一件事情不同角度。
9. 迪米特法则，又称最少知道原则（Demeter Principle）：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

3. 重构获得设计模式

在实际开发工作中，一件事情都希望能够有一个较好的规划，以方便后期开发工作能够顺利开展，减少不必要的问题。但不管是因为财力（优秀架构师）还是内容的首创性，实际情况往往事与愿违。现代工作内容都是在不断的试错迭代中探索好的方向，因此重构获得设计模式refactoring to patterns才是现代工作的黄金定律。

面向对象设计模式是“号的面向对象设计”，所谓“好的面向对象设计”指是哪些可以满足“应对变化，提高复用的设计”。

现代软件设计的特征是“需求的频繁变化”。设计模式的要点是寻找变化点，然后在变化点处应用设计模式，从而更好地应对需求的变化。

发现问题比解决问题更重要，要求开发人员深入的理解设计模式特性。但是什么时候、什么地点应用设计模式比理解设计模式的结构本省更重要。

设计模式的应用不易想入为主，一上来使用设计模式是对设计模式最大误用。当然也不可能原地踏步，不做任何代码的优化，放任问题存在，不做个人能力提升。没有一步到位的设计模式。敏捷开发实践提倡的“Refactoring to Patterns”是目前普遍公认最好的使用设计模式的方法。设计模式结束以后马上进入的一本书是《重构—改善机油代码的设计》。

重构关键技法：静态->动态 早绑定->晚绑定 继承->组合

编译时依赖->运行时依赖 紧耦合->松耦合。原则和技法是设计模式中非常重要的核心内容，是比设计模式本身更加重要的东西。这几种方法是同一个问题的不同角度？？？？？

“这《重构:改善既有代码的设计》之于重构就相当于韵谱之于作诗。一个翻着韵书作诗的诗人一定是蹩脚的，但好的诗人却要对那109个韵部了然于胸;同样，一个好的程序员要求能够主动自然地重构代码，虽不应翻着重构手册干活，但需对《重构:改善既有代码的设计》中提到的70多个重构方法成竹在胸。然而，在达到这一境界之前，需要不断的实践和经验积累，并且要先读读Fowler的这《重构:改善既有代码的设计》。”

4. 总结

随着时间的推移设计模式后期逐渐被语言特性替代，当然很多设计模式也可能逐渐被淘汰。但是，设计原则却一直存在，同时也在不断的其他设计模式中核心思想进来为设计模式增加新成员。设计原则作为设计标尺，是衡量设计模式正确与否的一个重要标准，其重要程度比设计模式更甚。

设计原则提升为设计经验。

1. 设计习语（Design Idioms）。描述与特定编程语言相关的底层模式，技巧，惯用法。
2. 设计模式（Design Patterns）。描述的是类与相互通信的对象之间的组织关系，包括它们的角色、职责、写作方式等方面。
3. 架构模式（Architectural patterns）。描述系统中与基本结构组织关系密切的高层模式，包括子系统划分，职责，以及如何组织它们之间的关系的规则。