设计模式总结

      设计模式总结

     （一）定义

      设计模式是面向对象语言程序设计的一种模式指导思想，旨在提高代码的可扩展性、可维护性以及可重复性和高灵活度。

      可扩展性：主要是面向接口编程，从而做到解耦。

      可维护性：设计模式讲究高内聚低耦合，强调封装变化等，能将特定的功能封装在一起，有利于维护。

      可重复性：封装、继承和多态使得易于复用。

     （二）分类

      可分为创建型、结构型、行为型。

      1.创建型

     对象的创建会消耗掉系统的很多资源，所以单独对对象的创建进行研究，从而能够高效地创建对象就是创建型模式要探讨的问题。

(1)简单工厂模式（SimpleFactory）http://blog.csdn.net/kangquan2008/article/details/7057438

(2)工厂方法模式（FactoryMethod）

(3)抽象工厂模式（AbstractFactory）

(4)创建者模式（Builder）

(5)原型模式（Prototype）

(6)单例模式（Singleton） 

2．结构型

如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。

(1)外观模式（Facade）

(2)适配器模式（Adapter）

(3)代理模式（Proxy）

(4)装饰模式（Decorator）

(5)桥模式（Bridge）

(6)组合模式（Composite）

(7)享元模式（Flyweight）

3．行为型模式

如果对象的行为设计的好，那么对象的行为就会更清晰，它们之间的协作效率就会提高。

(1)模板方法模式（TemplateMethod）

(2)观察者模式（Observer）

(3)状态模式（State）

(4)策略模式（Strategy）

(5)职责链模式（Chainof Responsibility）

(6)命令模式（Command）

(7)访问者模式（Visitor） 

(8)中介者模式（Mediator）

(9)备忘录模式（Memento）

(10)迭代器模式（Iterator）

     (11)解释器模式（Interpreter）

     (三)设计模式的原则

1.单一职责原则
(1)定义
就一个类而言，应该只有一个可能引起其变化的原因。
(2)原因
提供内聚性。
2.封装变化原则
(1)定义
将经常变化的部分进行抽象封装起来，以后需要修改的时候对这一部分进行处理则可，避免影响其他不变的部分。
(2)原因
需求是变化的，有效的封装能提供內聚性。
3.开放－封闭原则
(1)定义
指软件实体，包括类、模块、函数等应该支持扩展，但不应该修改
(2)原因
需求是变化的，在面对变化的需求时对程序的改动通过添加新代码而不是修改现有的代码，使得系统能在第一个版本上的接口继续开发，而修改可能会导致牵一发而动全身，比如说类A的 print()用于打印“hello”，且类A在类B、C和类D中使用。现在类D，其使用类A，不仅需要打印，而且需要先获取输入，再将“hello”和输入打印出来。如果直接修改类A的函数，则B和 C中的类A就不满足原来的要求了，从而导致麻烦的发生。如果支持扩展，根据原来的接口新写一个类A'，使用同样的接口实现先输入再打印的功能，然后在类D调用A'则可。
4.里氏代换原则
(1)如果客户(调用者)使用父类，那么一定可以使用子类去代换父类，而且客户不会感知到这一变化，从而解藕。
(2)可以通过对子类的修改和增加新功能，使得调用者使用了新的功能而且无需做过多的修改。
5.依赖倒转原则
(1)定义
指抽象不应该依赖于细节，细节应该依赖于抽象高层模块不应该依赖于底层模块，两个都应该依赖抽象。
(2)原因
一般来讲，高层模块是依赖于底层模块的，比如说去调用库函数，但这会影响耦合性，使之变大。举个例子，一开始使用了Mysql数据库，现在想换为SQLServer，如果不是依赖于抽象，则需要进行大幅度修改，因为每种数据库的接口都不一样，但如果我之前对其抽象了，则依赖于抽象，现在改数据库，我只需要重新实现抽象的接口就可以了。
6.最少知识原则
(1)定义
如果两个类不必直接通信，那么这两个类就不应当发生直接的相互作用。如果一个类需要调用另一个类的某一方法的话，可以通过第三者来转发这个调用。
(2)原因
类之间的耦合越弱，越利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。
例如：类A在类B中new了100次，如果需要将类A变为类B，则需要改100次，但如果是在工厂类，则只需要在工厂里改一次。
7.聚合／组合复用原则
(1)定义
尽量使用聚合／组合，少用继承。
(2)原因

优先使用对象的聚合／组合有利于每个类的封装并集中在单个任务上。这样类和类的继承层次就能保持较小的规模，从而更容易控制。

转载请标明本博客。