设计模式总结

1 简单工厂模式（Static Factory Method）

适用场景

1. 工厂类负责创建的对象比较少。
2. 客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心。
3. 由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。

优点

1. 工厂类是整个模式的关键。包含了必要的逻辑判断，根据外界给定的信息，决定究竟应该创建哪个具体类的对象。
2. 通过使用工厂类，外界可以从直接创建具体产品对象的尴尬局面摆脱出来，仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。明确了各自的职责和权利，有利于整个软件体系结构的优化。

缺点

1. 由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中，它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
2. 当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求。这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利。
3. 这些缺点在工厂方法模式中得到了一定的克服。

---

2 策略模式（Strategy）

适用场景

1. 多个类有不同的表现形式，每种表现形式可以独立成单独的算法。
2. 需要再不同情况下使用不同的算法，以后算法可能还会增加。
3. 对用户隐藏算法逻辑。

优点

1. 每个算法单独封装，减少了算法和算法调用者的耦合。
2. 合理使用继承有助于提取出算法中的公共部分。
3. 简化了单元测试。

缺点

1. 策略模式只适用于客户端知道所有的算法或行为的情况。
2. 策略模式造成很多的策略类，每个具体策略类都会产生一个新类。不过可以使用享元模式来减少对象的数量。

---

3 装饰模式（Decorator）

适用场景

1. 需要扩展一个类的功能，或给一个类添加附加职责。
2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。
4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

优点

1. Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。
2. 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

缺点

1. 这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。
2. 装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。
3. 装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。

---

4 代理模式（Proxy）

适用场景

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

优点

1. 职责清晰，真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件完成事务，附带的结果就是编程简洁清晰。
2. 代理对象可以在客户端和目标对象之间起到中介的作用，这样起到了中介的作用和保护了目标对象的作用。
3. 高扩展性

缺点

1. 在客户端和目标对象增加一个代理对象，会造成请求处理速度变慢。
2. 增加了系统的复杂度。

---

5 工厂方法模式（Factory Method）

适用场景

1. 工厂方法模式是new一个对象的替代品，所以在所有需要生成对象的地方都可以使用，但是需要慎重地考虑是否要增加一个工厂类进行管理，增加代码的复杂度。
2. 需要灵活的、可扩展的框架时，可以考虑采用工厂方法模式。
3. 工厂方法模式可以用在异构项目中，例如通过WebService与一个非Java的项目交互，虽然WebService号称是可以做到异构系统的同构化，但是在实际的开发中，还是会碰到很多问题，如类型问题、WSDL文件的支持问题，等等，从WSDL中产生的对象都认为是一个产品，然后由一个具体的工厂类进行管理，减少与外围系统的耦合。
4. 可以使用在测试驱动开发的框架下，例如，测试一个类A，就需要把与类A有关联关系的类B也同时产生出来，我们可以使用工厂方法模式把类B虚拟出来，避免类A与类B的耦合。目前由于JMock和EasyMock的诞生，该使用场景已经弱化了，读者可以在遇到此种情况时直接考虑使用JMock或EasyMock。

优点

1. 良好的封装性，代码结构清晰，减少模块间的耦合。
2. 工厂方法模式的扩展性非常优秀。
3. 屏蔽产品类。
4. 工厂方法模式是典型的解耦框架。

缺点

1. 使用者必须知道相应工厂的存在。
2. 每次增加一个产品时，都需要增加一个具体类和对象实现工厂，是的系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。

---

6 原型模式（Prototype）

适用场景

1. 某些结构复杂的对象的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口。
2. 一般在初始化的信息不发生变化的情况下，克隆是最好的方法。

优点

1. 隐藏了对象创建的细节。
2. 提高了性能。
3. 不用重新初始化，动态获得对象运行时的状态。

缺点

1. 适用性不是很广。
2. 每一个类必须配备一个克隆方法。
3. 配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。

---

7 模板方法模式（Template Method）

适用场景

1. 适用于子类中有重复的代码，可以把重复代码提取出来，放到父类中。

优点

1. 提高代码复用性。
2. 帮助子类摆脱重复的不变行为。

缺点

1. 考虑不全面统一出现问题。