一、设计模式基础
1.1 GoF的23种设计模式及其功能
- 单例（ Singleton ）模式 某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
- 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例
- 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生存什么产品
- 抽象工厂（Abstract Factory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品
- 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们
- 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性
- 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能在一起工作的那些类能一起工作
- 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化，它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
- 装饰（Decorator）模式：：动态的给对象增加一些职责，即增加其额外的功能
- 外观（ Facade ）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问
- 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用
- 组合（ Composite ）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性
- 模板方法（ Templat Method ）模式：定义一个操作中的算法骨架 ，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤
- 策略（ Strategy ）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户
- 命令（ Command ）模式：将一个请求封装为一个对象 ，使发出请求的责任和执行请求的责任分割开
- 职责链 （Chain of Responsibility ）模式：把请求从链中的一个对象传到下一个对象 ，直到请求被响应为止。通过这种方式去除对象之间的耦合
- 状态（ State ）模式：允许一个对象在其内部状态发生改变时改变其行为能力
- 观察者（ Observer 模式：多个对象间存在－对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为
- 中介者（ Mediator ）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解
- 迭代器 Iterator ）模式 提供一种方法来顺序访问聚合对象中的一系列数据 ，而不暴露聚合对象的内部表示
- 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合种的每个元素提供多种访问方式，即每个元素有多个访问者对象访问
- 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态以便以后恢复它
- 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器
二、面向对象的设计原则
2.1 开闭原则OCP
- 对扩展开放、对修改关闭
- 通过“抽象约束、封装变化”来实现开闭原则
- 抽象层设计的合理，可以基本保持软件架构的稳定
- 当软件需求发生变化时，只需要根据需求派生一个实现类来扩展就可以了
2.2 里氏替换原则LSP
- 子类可以扩展父类的功能，但不能改变父类原有的功能
- 简单来说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法
- 作用：实现开闭原则的重要方式之一、提高父类可复用性、降低类的扩展出错的可能性
- 如果出现因重写父类方法而导致出错的情况，应该设计个更一般的类，重新组织类的继承关系
2.3 依赖倒置原则DIP
- 要面向接口编程，不要面向实现编程
- 抽象层相对稳定，实现类较为多变
- 接口/抽象类的目的是制定好规范和契约，不去涉及任何具体的操作
- 具体细节的任务交给实现类完成
- 作用：降低了类间的耦合性、提高系统的稳定性、提高代码可读性和可维护性
2.3.1 实现方法
- 每个类尽量提供接口或抽象类，或者两者都具备
- 变量的声明类型尽量是接口或者是抽象类
- 任何类都不应该从具体类派生
- 使用继承时尽量遵循里氏替换原则
2.4 单一职责原则SRP
- 一个类应该有且仅有一个引起它变化的原因，否则应该被拆分
- 承担太多职责的缺点：削弱类实现其他职责的能力、冗余代码
- 作用：降低类的复杂度、提高类的可读性、提高系统可维护性、变更引起的风险降低
- 实现方法：分析、设计、重构
- 同样适用于方法，方法应尽可能做好一件事情
2.5 接口隔离原则ISP
- 程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法
- 要为类建立它们需要的专用接口，而不要视图去建立一个很庞大的接口供所有依赖它的类去调用
- 作用：提高系统灵活性和可维护性、降低系统耦合性、提高系统内聚性、接口粒度大小要定义合理（太大太小都不好）、减少代码冗余、能够体现对象的层次
实现方法：一个接口只服务于一个子模块或业务逻辑、为依赖接口的类定制服务、深入了解环境/业务逻辑、使接口用最少的方法实现最多的事情
2.6 迪米特法则LKP
- 如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用
- 作用：降低类间耦合度、提高模块相对独立性、提高类的可复用性和系统的扩展性
- 过渡使用LKP会使系统产生大量的中介类，从而增加系统的复杂性，所以使用时要权衡好
- 实现方法：依赖者应该依赖应该依赖的对象、被依赖者只暴露应该暴露的方法
- 注意：应创建弱耦合的类、降低类成员的访问权限、优先考虑设计不变类、降低引用次数、不暴露属性成员（提供get和set）、进行使用序列化
2.7 合成复用原则CRP
- 又称组合/聚合复用原则（CARP）
- 它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现
- 如果要使用继承关系，则必须严格遵循里氏代换原则
- 合成复用原则和里氏代换原则都是开闭原则的具体实现规范
- 类的复用包括：继承复用、合成复用
2.7.1 继承复用
- 破坏了类的封装性，父类暴露给子类
- 子类与父类耦合度高
- 限制了复用的灵活性，父类继承而来的实现是静态的，在编译时已经定义、所以在运行时不可能发生变化
2.7.2 合成复用
- 维持了类的封装性
- 新旧类之间的耦合度低
- 复用的灵活性高，可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象