本周学习代码重构，个人主要针对23种gof设计模式进行学习和总结

设计模式总结

软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。



设计模式分类

单例（Singleton）模式

指一个类只有一个实例，且该类能自行创建这个实例的一种模式。

单例模式的优点：

• 单例模式可以保证内存里只有一个实例，减少了内存的开销。

• 可以避免对资源的多重占用。

• 单例模式设置全局访问点，可以优化和共享资源的访问。

单例模式的缺点：

• 单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则。

• 在并发测试中，单例模式不利于代码调试。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。

• 单例模式的功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责原则。

原型（Prototype）模式

用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型相同或相似的新对象。

优点:

• Java 自带的原型模式基于内存二进制流的复制，在性能上比直接 new 一个对象更加优良。

• 可以使用深克隆方式保存对象的状态，使用原型模式将对象复制一份，并将其状态保存起来，简化了创建对象的过程，以便在需要的时候使用（例如恢复到历史某一状态），可辅助实现撤销操作。

缺点:

• 需要为每一个类都配置一个 clone 方法

• clone 方法位于类的内部，当对已有类进行改造的时候，需要修改代码，违背了开闭原则。

• 当实现深克隆时，需要编写较为复杂的代码，而且当对象之间存在多重嵌套引用时，为了实现深克隆，每一层对象对应的类都必须支持深克隆，实现起来会比较麻烦。

工厂方法（Factory Method）模式

定义一个用于创建产品的接口，由子类决定生产什么产品。

优点:

• 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程。

• 灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。

• 典型的解耦框架。高层模块只需要知道产品的抽象类，无须关心其他实现类，满足迪米特法则、依赖倒置原则和里氏替换原则。

缺点:

• 类的个数容易过多，增加复杂度

• 增加了系统的抽象性和理解难度

• 抽象产品只能生产一种产品，此弊端可使用抽象工厂模式解决。

抽象工厂（AbstractFactory）模式

提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。

优点：

• 可以在类的内部对产品族中相关联的多等级产品共同管理，而不必专门引入多个新的类来进行管理。

• 当需要产品族时，抽象工厂可以保证客户端始终只使用同一个产品的产品组。

• 抽象工厂增强了程序的可扩展性，当增加一个新的产品族时，不需要修改原代码，满足开闭原则。

缺点：

• 当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。增加了系统的抽象性和理解难度。

建造者（Builder）模式

将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

建造者（Builder）模式和工厂模式的关注点不同：建造者模式注重零部件的组装过程，而工厂方法模式更注重零部件的创建过程，但两者可以结合使用。

优点：

• 封装性好，构建和表示分离。

• 扩展性好，各个具体的建造者相互独立，有利于系统的解耦。

• 客户端不必知道产品内部组成的细节，建造者可以对创建过程逐步细化，而不对其它模块产生任何影响，便于控制细节风险。

缺点：

• 产品的组成部分必须相同，这限制了其使用范围。

• 如果产品的内部变化复杂，如果产品内部发生变化，则建造者也要同步修改，后期维护成本较大。

代理（Proxy）模式

为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。适配器模式是更换接口访问适用新的工作。

优点：

• 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用；

• 代理对象可以扩展目标对象的功能；

• 代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度，增加了程序的可扩展性

缺点：

• 代理模式会造成系统设计中类的数量增加

• 在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢；

• 增加了系统的复杂度；

适配器（Adapter）模式

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。

适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

优点：

• 客户端通过适配器可以透明地调用目标接口。

• 复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类。

• 将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题。

缺点：

• 对类适配器来说，更换适配器的实现过程比较复杂。

桥接（Bridge）模式

将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

优点：

• 由于抽象与实现分离，所以扩展能力强；

• 其实现细节对客户透明。

缺点：

• 由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，这增加了系统的理解与设计难度。

装饰（Decorator）模式

动态的给对象增加一些职责，即增加其额外的功能。

外观（Facade）模式

为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。

享元（Flyweight）模式

运用共享技术来有效地支持大量细粒度对象的复用。

组合（Composite）模式

将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

模板方法（TemplateMethod）模式

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

策略（Strategy）模式

定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。

命令（Command）模式

将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。

职责链（Chain of Responsibility）模式

把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

状态（State）模式

允许一个对象在其内部状态发生改变时改变其行为能力。

观察者（Observer）模式

多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。

中介者（Mediator）模式

定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。

迭代器（Iterator）模式

提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

访问者（Visitor）模式

在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。

备忘录（Memento）模式

在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。

解释器（Interpreter）模式

提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。