设计模式学习笔记--引言（一）

设计模式 学习笔记

1 引言

1.1 什么是设计模式

“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”

一般而言，一个模式有四个基本要素：

1. 模式名称（pattern name） 一个助记名，它用一两个词来描述模式的问题、解决方案和效果。

2. 问题(problem) 描述了应该在何时使用模式。它

3. 解决方案(solution) 描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。

4. 效果(consequences) 描述了模式应用的效果及使用模式应权衡的问题。

1.2 设计模式的编目

Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

A d a p t er：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

B r i d g e：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

B u i l d e r：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

Chain of Responsibility：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

C o m m a n d：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。

C o m p o s i t e：将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e使得客户对单个对象和复合对象的使用具有一致性。

D e c o r a t o r：动态地给一个对象添加一些额外的职责。就扩展功能而言， D e c o r a t o r模式比生成子类方式更为灵活。

F a c a d e：为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

Factory Method：定义一个用于创建对象的接口，让子类决定将哪一个类实例化Factory Method使一个类的实例化延迟到其子类。

F l y w e i g h t：运用共享技术有效地支持大量细粒度的对象。

I n t e r p r e t e r：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。

I t e r a t o r：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。

M e d i a t o r：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

M e m e n t o：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。

O b s e r v e r：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。

P r o t o t y p e：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。

P r o x y：为其他对象提供一个代理以控制对这个对象的访问。

S i n g l e t o n：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

S t a t e：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。

S t r a t e g y：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。

Template Method：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

Vi s i t o r：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

1.3 组织编目

设计模式在粒度和抽象层次上各不相同。由于存在众多的设计模式，我们希望用一种方式将它们组织起来。这一节将对设计模式进行分类以便于我们对各族相关的模式进行引用。



第一是目的准则，即模式是用来完成什么工作的。模式依据其目的可分为创建型（ C r e a t i o n a l ）、结构型( S t r u c t u r a l )、或行为型( B e h a v i o r a l )三种。创建型模式与对象的创建有关；结构型模式处理类或对象的组合；行为型模式对类或对象怎样交互和怎样分配职责进行描述。

第二是范围准则，指定模式主要是用于类还是用于对象。类模式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了。对象模式处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性。从某种意义上来说，几乎所有模式都使用继承机制，所以“类模式”只指那些集中于处理类间关系的模式，而大部分模式都属于对象模式的范畴。

创建型类模式将对象的部分创建工作延迟到子类，而创建型对象模式则将它延迟到另一个对象中。结构型类模式使用继承机制来组合类，而结构型对象模式则描述了对象的组装方式。行为型类模式使用继承描述算法和控制流，而行为型对象模式则描述一组对象怎样协作完成单个对象所无法完成的任务。

2 设计原则

2.1 单一职责原则（SRP）

Single Responsibility Principle,单一职责原则：应该有且仅有一个原因引起类的变更。将类的职责分开，如果一个类中包含了两个职责，而且这两个职责没有相互影响，那么就考虑拆开成两个接口。
这样的好处：1、类的负责性降低；2、可读性提高；3、可维护性提高；4、变更引起的风险降低。

2.2 里氏替换原则（LSP）

Liskov Substitution Principle, 所有引用基类的地方，都可以用子类替换。但反过来父类就未必适应了，里式替换包含了四层意思：
子类必须完全的实现父类的方法；子类可以有自己的个性；覆盖或实现父类的方法的时候输入参数可以被放大；覆盖或者实现父类的方法输出结果可以被缩小。

2.3 依赖倒置原则（DIP）

Dependence Inversion Priciple,概要的说就是“面向接口编程”。高层模块不应该依赖底层模块，抽象不应该依赖细节，细节应该依赖抽象。依赖的三种写法：构造函数传递依赖对象；setter方法传递依赖对象；接口方法中声明依赖对象

2.4 接口隔离原则（ISP）

Interface Segregation Priciple,类间的依赖必须建立在最小的接口上。通俗的讲就是接口尽量细化，同时接口中的方法尽量的少。接口隔离原则拆分接口时，必须首先满足单一职责原则。接口要高内聚。

2.5 迪米特法则（LSP）

迪米特法则也叫最小知识原则，通俗的讲就是一个类对自己需要耦合或者调用的类知道的越少越好。包括几层意思：只和朋友交流，出现在成员变量、方法的输入输出参数中的类称为朋友类；朋友类也是有距离的，迪米特法则要求类，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛。

2.6 开闭原则（OCP）

Open Close Principle,软件实体应该对扩展开放，对修改关闭。与修改接口和修改实现类相比，通过扩展实现变化，有以下好处：可以提高复用性，可维护性