软件设计模式

单件模式（Singleton Pattern）

• 概述

Singleton模式要求一个类有且仅有一个实例，并且提供了一个全局的访问点。这就提出了一个问题：如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？客户程序在调用某一个类时，它是不会考虑这个类是否只能有一个实例等问题的，所以，这应该是类设计者的责任，而不是类使用者的责任。

从另一个角度来说，Singleton模式其实也是一种职责型模式。因为我们创建了一个对象，这个对象扮演了独一无二的角色，在这个单独的对象实例中，它集中了它所属类的所有权力，同时它也肩负了行使这种权力的职责！

• 意图

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

• 生活中的例子

美国总统的职位是Singleton，美国宪法规定了总统的选举，任期以及继任的顺序。这样，在任何时刻只能由一个现任的总统。无论现任总统的身份为何，其头衔"美利坚合众国总统"是访问这个职位的人的一个全局的访问点。

• 优点

l 实例控制：Singleton 会阻止其他对象实例化其自己的 Singleton 对象的副本，从而确保所有对象都访问唯一实例

l 灵活性：因为类控制了实例化过程，所以类可以更加灵活修改实例化过程

• 缺点

l 开销：虽然数量很少，但如果每次对象请求引用时都要检查是否存在类的实例，将仍然需要一些开销。可以通过使用静态初始化解决此问题，上面的五种实现方式中已经说过了。

l 可能的开发混淆：使用 singleton 对象（尤其在类库中定义的对象）时，开发人员必须记住自己不能使用 new 关键字实例化对象。因为可能无法访问库源代码，因此应用程序开发人员可能会意外发现自己无法直接实例化此类。

l 对象的生存期：Singleton 不能解决删除单个对象的问题。在提供内存管理的语言中（例如基于 .NET Framework 的语言），只有 Singleton 类能够导致实例被取消分配，因为它包含对该实例的私有引用。在某些语言中（如 C++），其他类可以删除
对象实例，但这样会导致 Singleton 类中出现悬浮引用。

• 适用性

l 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。

l 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

• 应用场景

l 每台计算机可以有若干个打印机，但只能有一个Printer Spooler，避免两个打印作业同时输出到打印机。
（摘自吕震宇的C#设计模式（7）－Singleton Pattern）

l PC机中可能有几个串口，但只能有一个COM1口的实例。

l 系统中只能有一个窗口管理器。

l .NET Remoting中服务器激活对象中的Sigleton对象，确保所有的客户程序的请求都只有一个实例来处理。

抽象工厂模式（Abstract Factory）

• 概述

在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时由于需求的变化，往往存在着更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象的创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？这就是我们要说的抽象工厂模式。

• 意图

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

• 生活中的例子

抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以汽车制造厂所使用的金属冲压设备中找到。这种冲压设备可以制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。

• 优点

l 分离了具体的类。抽象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。

l 它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。

l 它有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要，而抽象工厂很容易实现这一点。

• 缺点

l 难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几口确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。

• 适用性

在以下情况下应当考虑使用抽象工厂模式：

l 一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。

l 这个系统有多于一个的产品族，而系统只消费其中某一产品族。

l 同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。

l 系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

• 应用场景

l 支持多种观感标准的用户界面工具箱（Kit）。

l 游戏开发中的多风格系列场景，比如道路，房屋，管道等。

l ……

• 总结

总之，抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，运用抽象工厂模式的关键点在于应对“多系列对象创建”的需求变化。一句话，学会了抽象工厂模式，你将理解OOP的精华：面向接口编程。

观察者模式（Observer Pattern）

• 概述
  在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
• 意图

定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。[GOF 《设计模式》]

• 生活中的例子

观察者定义了对象间一对多的关系，当一个对象的状态变化时，所有依赖它的对象都得到通知并且自动地更新。拍卖演示了这种模式。每个投标人都有一个标有数字的牌子用于出价。拍卖师开始拍卖时，他观察是否有牌子举起出价。每次接受一个新的出价都改变了拍卖的当前价格，并且广播给所有的投标人进行新的出价

• 适用性

1．当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。

2．当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。

3．当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。

• 总结

通过Observer模式，把一对多对象之间的通知依赖关系的变得更为松散，大大地提高了程序的可维护性和可扩展性，也很好的符合了开放-封闭原则。

适配器模式（Adapter Pattern）

• 引言

在实际的开发过程中，由于应用环境的变化，我们需要的实现在新环境中没有现存对象可以满足，但是其他环境却存在这样现存的对象。如何在新环境中调用“现存的对象”呢？采用适配器模式可以解决。适配器模式使得新环境中不需要去重复实现已经存在了的实现，而很好的把现有的对象（指原来环境中的现有对象）加入到新环境中来使用。

• 详细介绍

定义:把一个类的接口变换成客户端所期待的另一种接口，从而使得原本接口不匹配而无法一起工作的两个类能够一起工作。适配器模式有类的适配器模式和对象的适配器模式。

• 生活中的例子

在生活中，我们买的电器插头是两个孔的，但是我们买的插座只有三个孔的，此时我们就希望电器的插头可以转换为三个孔的就好了，这样我们就可以直接插在插座上，此时三个孔插头就是客户端期待的另一种接口，自然两个孔的插头就是现有的接口，适配器模式就是用来完成这种转换的。
适配器模式的优缺点

类的适配器模式

• 优点：

可以在不修改原有代码的基础上，很好的符合“开闭原则”
可以重新定义Adaptee（被适配的类）的部分行为，因为在类适配器模式中，Adapter是Adaptee的子类
仅引入一个对象，并不需要额外的字段来引用Adaptee实例

• 缺点：

用一个具体的Adapter类对Adaptee和Target进行匹配，当如果想要匹配一个类以及所有它的子类时，类的适配器模式就不能胜任了。因为类的适配器模式中没有引入Adaptee的实例，光调用this.SpecificRequest方法并不能去调用它对应子类的SpecificRequest方法
采用了 “多继承”的实现方式，带来了不良的高耦合。
对象的适配器模式

• 优点：

可以在不修改原有代码的基础上来复用现有类，很好地符合 “开闭原则”（这点是两种实现方式都具有的）
采用 “对象组合”的方式，更符合低耦合。

• 缺点：

使得重定义Adaptee的行为较困难，这就需要生成Adaptee的子类并且使得Adapter引用这个子类而不是引用Adaptee本身。

• 使用场景

在以下情况下可以考虑使用适配器模式：

1. 系统需要复用现有类，而该类的接口不符合系统的需求
2. 想要建立一个可重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。
3. 对于对象适配器模式，在设计里需要改变多个已有子类的接口，如果使用类的适配器模式，就要针对每一个子类做一个适配器，而这不太实际。
   总结
   适配器可以是抽象类，并适配器模式的实现是非常灵活的，我们完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，适配器类可以根据参数参数可以返回一个合适的实例给客户端。类的适配器模式是定义一个接口来实现客户端想要的方法，并在适配器类中继承这个接口和源角色。对象的适配器模式是在适配器类中继承要适配的类并声明一个源角色的对象，通过重写调用基类的方法来实现。