大话设计模式学习笔记

本文是自己学习《大话设计模式》的读书笔记，在我看来对于面向对象的语言书中讲到的23种模式设计就好比是武术中的降龙十八掌，只要学习并熟练运用就能成为武林高手，本人也是抱着这个目标去学习，希望自己不要只是纸上谈兵能够在实践中渐渐熟练使用。

模式设计的一些原则

单一职责原则（SRP）：
就一个类而言，应该仅有一个引起它变化的原因。
为什么要：
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受意想不到的破坏。
怎么去做：
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离，判断是否应该分离出类来，就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。
开放-封闭原则：
软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。
为什么：
在做任何系统的时候，都不要指望系统一开始需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。设计面对需求的改变可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本。
带来的好处：开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。
怎么做：
1、 无论模块多么的‘封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化的种类，然后构造抽象来隔离那些变化。
2、 在最初编码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。
3、 面对需求，对程序的改动是通过增加新代码进行的，而不是更改现在的代码。
4、 希望在开发工作展开不久就知道可能发生的变化，查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。

依赖倒置原则：
A、 高层模块不应该依赖低模块。两个都应该依赖抽象。
B、 抽象不应该依赖细节。细节应该依赖抽象。

里氏代换原则：
子类型必须能够替换掉它们的父类型。
为什么：
子类型可替换性才使得父类型的模块在无需修改的情况下就可以扩展。

迪米特法则（最少知识原则）：
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
原则：（在类的结构设计上，每一个类都应当尽量降低成员的访问权限）
为什么：
迪米特法则根本思想是强调了类之间的松耦合，类之间的耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。

合成/聚合复用原则
尽量使用合成/聚合，尽量不要使用类继承。

优点：有助于保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。
23种设计模式：
1、 单例模式
2、 工厂方法模式
3、 抽象工厂模式
4、 建造者模式
5、 原型模式
6、 适配器模式
7、 装饰模式
8、 桥接模式
9、 组合模式
10、 享员模式
11、 代理模式
12、 外观模式
13、 观察者模式
14、 模板方法模式
15、 命令模式
16、 状态模式
17、 职责链模式
18、 解释器模式
19、 中介者模式
20、 访问者模式
21、 策略模式
22、 备忘录模式
23、 迭代器模式

抽象工厂模式

优点：易于交换产品系列，由于具体工厂类在一个应用中只需要初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它需要改变具体工厂即可使用不同产品配置。
它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

建造者模式

将一个复杂的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
优点：
如果我们用了建造者模式，那么用户就只需要指定需要建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道。
适用范围：
建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。

原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
注：会涉及到浅复制和深复制的问题

装饰模式

动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
优点：
1、 把类中的装饰功能从类中搬移去除，这样可以简化原有的类。
2、 有效地把类的核心职责和装饰功能区分开；而且可以去除相关类中重复的装饰逻辑。

桥接模式

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

组合模式

将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。

享元模式

如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享员模式。

代理模式

为其他对象提供一种代理以控制对这个对象的访问
1、 远程代理，也就是为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。
2、 虚拟代理，根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。
3、 安全代理，用来控制真实对象访问时的权限。
4、 智能指引，指当调用真实的对象时，代理处理另外一些事情。

外观模式

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

观察者模式（发布-订阅模式）

定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。
在观察者模式介绍中有一个叫做事件委托的实现（在平时使用过程中可以通过指针函数变量的形式实现）
事件委托说明：
委托就是一种引用方法的类型，一旦为委托分配了方法，委托将与该方法具有完全相同的行为。委托方法的使用可以像其他任何方法一样，具有参数和返回值。委托可以看作是对函数的抽象，是函数的‘类’，委托的实例将代表一个具体的函数。
模板方法模式

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

命令模式

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

状态模式

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
状态模式主要解决的是控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。

职责链模式

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
优点：
当客户提交一个请求时，请求是沿链传递至有一个concreteHandler对象负责处理它。

解释器模式

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
优点：
容易地改变和扩展文法，因为该模式使用类来表示文法规则，你可使用继承来改变或扩展该文法。也比较容易实现文法，因为定义抽象语法树中各个节点的类的实现大体类似，这些类都易于直接编写。
不足：
解释器模式为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时，使用其他的技术如语法分析程序或编译器生成器来处理。

中介者模式

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
优点：
Mediator的出现减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator；其次，由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待系统。
缺点：
由于ConcreteMediator控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂。

访问者模式

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。

策略模式

定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户。

备忘录模式

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

迭代器模式

提供一种方法顺序访问一个集合对象中的各个元素，而各不暴露该对象的内部表示。

适配器模式

工厂模式、工厂方法模式和抽象工厂模式之间的区别
简单工厂模式：如果增加新的产品，同时也需要修改工厂类

工厂方法：可以任意增加产品和工厂类不会造成其他产品和工厂类的修改；但是需要修改客服端的代码。

抽象工厂模式：增加产品类会导致具体工厂和抽象工厂的修改，当时如果增加具体工厂（产品族）将非常容易，并且不会影响到其他的类。对于抽象工厂的弱点可以使用反射，这样可以避免增加工厂类导致的工厂类和抽象类的修改避免耦合的出现。