《设计模式之禅》(第2版)

第一部分  大旗不挥  谁敢冲锋 —— 6大设计原则全新解读

第1章  单一职责原则

单一职责原则，Single Responsibility Principle，简称SRP，有且只有一个原因引起类/接口的变更；即一个接口/类只有一个职责，只负责一件事情。

单一职责的好处：

1. 类的复杂性降低。实现什么职责都有清晰明确的定义；
2. 可读性提高，复杂性降低；
3. 可维护性提高；
4. 变更引起的风险降低

面向接口编程，对于接口的设计要求接口职责做到单一。

单一职责原则使用于接口、类，同时使用于方法。保证一个方法尽可能的只负责一件事。

最佳实践：接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

---

第2张  里氏替换原则

面向对象语言中，继承是必不可少的，其优缺点如下：

优点：

1. 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
2. 提高代码的重用性；
3. 子类形似父类又不同于父类；
4. 提高产品或项目的开放性

缺点：

1. 继承是侵入性的。只要子类继承父类，就必须拥有父类的所有方法和属性。
2. 降低代码的灵活性。必须拥有父类的方法和属性。
3. 增强了耦合性。

里氏替换原则，Liskov Substitution Principle，简称LSP , 所有引用基类的地方必须能透明地使用其子类对象。即父类能出现的地方子类就可以出现，而且替换为子类不会产生任何影响或异常，但是反过来不行，有子类出现的地方，父类未必能适应。

里氏替换原则为良好的继承定义了一个规范，含义如下：

1. 子类必须完全实现父类的方法
2. 子类可以有自己的个性
3. 覆盖或者实现父类方法时输入参数可以被放大
4. 覆盖或者实现父类方法是输出结果可以被缩小

采用里氏替换原则的目的：增强程序的健壮性，版本升级时也能保证很好的兼容性。

最佳实践：在项目中，采用里氏替换原则时，尽量避免子类的个性。

---

第3章  依赖倒置原则

依赖倒置原则，Dependence Inversion Principle，简称DIP，改原则在Java中的表现：

1. 模块之间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的。
2. 接口或抽象类不依赖于实现类
3. 实现类依赖接口或抽象类

更加精简的定义就是：面向接口编程。

依赖的3种写法：

1. 构造函数传递依赖对象，构造注入
2. Setter方法传递依赖对象，Setter注入
3. 接口声明依赖对象，接口注入

最佳实践：  

依赖倒置原则本质是用过抽象（接口或抽象类）使各个类或者模块实现彼此独立，不相互影响，实现模块间的松耦合。只需遵循以下规则即可：

1. 每个类尽量都有接口或者抽象类，或者接口和抽象类都具备
2. 变量的表面类型尽量是接口或者抽象类
3. 任何类都不应该从不具体类派生
4. 尽量不要重写父类的方法
5. 结合里氏替换原则使用

---

第4章  接口隔离原则

接口隔离原则：  客户端不应该依赖它不需要的接口，类之间的依赖关系应该建立在最小的接口上。即建立单一接口，不要建立臃肿庞大的接口。也即接口尽量要细化，接口中的方法尽量少。

---

第5章  迪米特法则

迪米特法则，最小知识原则，Law of Demeter，简称LoD。一个对象应该对其他对象有最少的了解。即一个类应该对自己需要耦合或调用的类知道的最少。

迪米特法则核心：类间解耦，弱耦合。

---

第6章  开闭原则

开闭原则：一个软件实体如类、模块、函数应该对扩展开发，对修改关闭。即一个软件实体应该通过扩展实现变化，而不是通过修改已有的代码实现变化。

SOLID

Single  Responsibility Principle 单一职责原则，

Open Closed Principle 开闭原则，

Liskov, Substitution  Principle 里氏替换原则 ，

Law of Demeter 迪米特法则，

Interface Segregation Principle 接口隔离原则,

Dependence Inversion Principle 依赖倒置原则

---

第二部分  真刀实枪——23种设计模式完美演绎

第7章  单例模式

单例模式：确保某个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

单例模式优缺点：

优点：

1. 由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建、销毁时，而且创建销毁的时的性能又无法优化，单例模式的优势比较明显；
2. 由于单例模式在内存中只有一个实例，减少了系统的性能开销，当一个对象的产生需要比较多的资源时，例如读取配置、产生其他依赖对象时，可以通过单例模式来解决；
3. 单例模式避免对资源的多重占用，例如一个写文件动作，由于只有一个实例在内存中，避免对同一个资源文件的同时写操作；
4. 单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如可以使用单例模式负责所有数据表的映射处理；

缺点：

1. 单利模式无接口，扩展比较困难；
2. 单例模式对测试不利；
3. 单例模式与单一职责原则有冲突；

单例模式使用场景： 

在一个系统中，要求一个类有且只有一个对象，如果出现多个对象会出现不良反应，可以采用单例模式，具体场景如下：

1. 要求生成唯一序列号的场景；
2. 在整个项目中需要一个共享访问点或者共享数据，例如一个web页面上的计数器。
3. 创建一个对象需要消耗的资源过多，例如要访问IO和数据库等资源；
4. 需要定义大量的静态常量和静态方法的环境。

注意事项：

1. 多线程环境下的单例模式的线程同步问题。
2. 注意对象的复制情况，一般情况下单例模式不需要被复制，让单例类不要实现Cloneable接口。

最佳实践：

例如Spring中的Bean是单例的，这样可以使得Spring容器管理这些Bean的生命周期。

---

第8章  工厂方法模式

工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法模式是一个类的实例化延迟到其子类。

在工厂方法模式中，抽象产品类Product负责定义产品的共性，实现对事物最抽象的定义；Creator为抽象创建类，也就是抽象工厂，具体如何创建产品类由具体的实现工厂完成。

工厂方法模式的优点：

1. 良好的封装性，代码结构清晰。
2. 工厂方法模式的扩展性很好。
3. 屏蔽产品类。
4. 典型的解耦合框架。

工厂方法模式的使用场景：

1. 工厂方法模式是new一个对象的替代品，所以在所有需要生成对象的地方都可以使用，但是需要考虑是否需要增加一个工厂类进行管理，增加代码的复杂度。
2. 需要灵活的、可扩展的框架时，可以考虑采用工厂方法模式。
3. 可以用在异构的项目中。

工厂方法模式的扩展：

1. 缩小为简单工厂模式
2. 升级为多个工厂类
3. 替代单例模式
4. 延迟初始化

---

第9章  抽象工厂模式

抽象工厂模式：为创建一组相关或者相互依赖的对象提供一个接口，而且无须指定它们的具体类。

抽象工厂模式是工厂方法模式的升级版本，在多个业务品种、业务分类时，通过抽象工厂模式产生需要的对象是一种非常好的解决方式。

抽象工厂优缺点：

优点：

1. 封装性，每个产品的实现类高层模块不关心
2. 产品族内的约束为非公开状态。

缺点：

1. 产品族扩展困难。

---

第10章  模板方法模式

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

模板方法模式使用Java的继承机制，其中，AbstractClass是抽象模板，其方法分为2类：

1. 基本方法：  由子类实现的方法，并且在模板方法中被调用。访问权限尽量设置为protected类型
2. 模板方法：  一个或多个，一般是一个具体的方法，也就是一个框架，实现对基本方法的调度，完成固定的逻辑。为了防止恶意操作，一般模板方法都加上final修饰。

模板方法模式优缺点：

优点：

1. 封装不可变部分，扩展可变部分
2. 提取公共部分代码，便于维护
3. 行为由父类控制，子类实现。

缺点：

1. 模板方法模式定义部分抽象方法，由子类实现，子类执行的结果影响父类的结果。代码阅读有难度。

模板方法模式使用场景：

1. 多个子类有公有的方法，并且逻辑基本相同时使用。
2. 重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能由各个子类实现。
3. 重构时，模板方法模式经常使用，把相同的代码抽取到父类中，然后通过钩子函数约束其行为。

---

第11章  建造者模式

建造者模式，又称生产者模式：讲一个复杂兑现给的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

建造者模式通常有如下4中角色：

1. Product产品类 ： 通常实现了模板方法模式。
2. Builder抽象建造者：  规范产品的组建，一般由子类实现。
3. ConcreateBuilder具体建造者：  实现抽象类定义的所有方法，并且返回一个组建好的对象。
4. Director导演类：  负责安排已有模块的顺序，然后告诉建造者开始构建。

建造者模式优缺点：

优点：

1. 封装性。 使用建造者模式客户端不需要知道产品内部的实现细节。
2. 建造者独立，容易扩展。
3. 便于控制细节风险。

建造者模式的使用场景：

1. 相同的方法，不同的执行顺序，产生不同的事件结果时，可以使用建造者模式。
2. 多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同，则可以使用建造者模式。
3. 产品类非常复杂，或者产品类中的调用顺序不同产生不同的效能，此时采用建造者模式。
4. 在对象创建过程中会使用到系统中的一些其他对象，这些对象在产品对象的创建过程中不易得到是，可以使用建造者模式。

建造者模式注意事项：建造者模式关注的是零件的类型和装配工艺（顺序）。

---

第12章  代理模式

代理模式，委托模式：为其他对象提供一种代理以控制对这个对象的访问。

---

第13章  原型模式

原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

原型模式的核心是clone()方法，通过该方法进行对象的拷贝，Java提供了一个Cloneable接口标识这个对象是可以拷贝的。

原型模式的优点：

1. 性能优良。原型模式是在内存二进制流的拷贝，比直接new一个对象性能好很多，特别是循环体内产生大量的对象时，原型模式优点明显。
2. 逃避构造函数的约束。

原型模式使用场景：

1. 资源优化场景。类初始化需要消耗很多资源，例如数据、硬件资源等
2. 性能和安全要求的场景。new一个对象需要非常繁琐的数据准备或者访问权限，可以使用原型模式。
3. 一个对象多个修改者的场景。

原型模式注意事项：

1. 构造函数不会被执行。
2. 浅拷贝和深拷贝。
3. clone和final是有冲突的。

---

第14章   中介者模式

中介者模式：用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变他们之间的交互。

中介者模式组成部分：

1. Mediator 抽象中介者角色：定义统一的接口，用于各个同事角色之前的通信
2. Concrete Mediator 具体中介者角色： 具体中介者角色通过协调各个同事角色实现协作行为。
3. Colleague 同事角色：每个同事角色都知道中介者角色，而且其他同事角色通信的时候，一定要通过中介者角色协调。

---

第15章  命令模式