常用设计模式的一些优缺点

桃扇骨 2021-06-26 16:06 497阅读 0赞

## 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.  配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。