大话设计模式学习笔记

本文是自己学习《大话设计模式》的读书笔记，在我看来对于面向对象的语言书中讲到的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、 中介者模