10设计模式

Abstract Factory，也经常称之为抽象工厂模式

（1）object new ClassName 是最常见的创建对象方法，但这种方法造成类名的硬编码，需要根据不同的运行环境动态加载相同接口但实现不同的类实例，这样的创建方法就需要配合上复杂的判断，实例化为不同的对象

（2）为了适用于不同的运行环境，经常使用抽象类定义接口，并在不同的运行环境中实现这个抽象类的子类。普通的创建方式必然造成代码同运行环境的强绑定，软件产品无法移植到其他的运行环境

Abstract Factory 类将接受 Client 的“订单”——Client 发送过来的消息，使用不同的“车间”——不同的 Concrete Factory，根据已有的“产品模型”——Abstract Product，生产出特定的“产品”——Product。不同的车间生产出不同的产品供客户使用，车间与产品的关系是一一对应的。由于所有的产品都遵循产品模型——AbstractProduct，具有相同的接口，所以这些产品都可以直接交付客户使用

应用 Abstract Factory 模式可以实现对象可配置的、动态的创建。灵活运用 AbstractFactory 模式可以提高软件产品的移植性，尤其是当软件产品运行于多个平台，或有不同的功能配置版本时，抽象工厂模式可以减轻移植和发布时的压力，提高软件的复用性

Product Factory 既可以看作抽象工厂 Abstract Factory，也可以看作具体的 工厂（车间） Concrete Factory 。其中提供了一个获得产品的方法： getProduct （productName:String），该方法将根据产品的名称创建特定的产品，并返回。所有的产品都实现了 Product 接口，可以在客户程序中加以使用。同抽象工厂模式一样，工厂中获得对象的方法（getProduct()）与实际的产品线数量是一致的，如果要增加新的产品线——例如定义新的产品接口 ProductX，需要增加相应的 getProduct()方法。由于这种方式把 AbstractFactory 和 Concrete Factory 合并为一个 Product Factory，所以增加新的实现 Product 接口的 Productn 不需要修改任何代码

① 可配置的对象创建方法可以提高系统的移植性和复用性

② 充分利用面向对象多态的特性可以避免对象创建过程的硬编码

Singleton，也常称之为单件模式或单根模式

在软件开发中，开发人员希望一些服务类有且仅有一个实例供其他程序使用。例如，短消息服务程序或打印机服务程序，甚至对于系统配置环境的控制，为了避免并发访问造成的不一致，也希望仅为其他程序提供一个实例

在 Singleton 中，通过将 Singleton 类的构造函数设为 protected 型（或 private）来防止外部对其直接初始化。需要访问 Singleton 的程序必须通过 getInstance()方法来获得一个 Singleton。在getInstance() 中仅创建一次 uniqueInstance 就可以保证系统中的唯一实例

使用 Singleton 模式可以保证系统中有且仅有一个实例，这对于很多服务类或者环境配置类来说非常重要

需要注意

Decorator 模式，又称装饰模式或油漆工模式

在开发时，经常会发现为类预先设计的功能并不够强大，需要增强或扩展类的功能。解决这个问题的最简单的办法是继承出一个新的类，并扩展相应的方法。但是这样做会产生大量的子类，让系统中类的层次结构变得复杂且混乱。Decorator 模式通过在原有类的基础上包装一层来解决功能扩展的问题

DecoratorComponent 是 ConcreteComponent 的装饰类，它们继承自同一个抽象类Component，拥有相同的接口。对于 ConcreteComponent 的装饰可能不止一种，因此又继承出 ConcreteDecorator1 和 ConcreteDecorator2 来作为具体的装饰类。这个结构在类层次上是很清晰的，比静态继承更具有灵活性

Decorator 模式可以动态地扩展类的功能，同时又避免继承出大量的子类，比继承的方法更灵活。由于 Decorator 提供了动态的扩展方法，因此可以随时根据具体需求产生新的装饰类，从而可以在一定程度上避免层次较高类的复杂性。但是大量使用 Decorator 模式会造成系统中出现很多接口类似的小装饰对象，这样就造成系统可维护性的下降

Decorator 模式提供了一种动态为类扩展功能的方法，有着较广的应用 同其他模式一样，滥用 Decorator 会降低系统的可维护性。如果开发出来的装饰类仅被单一的地方使用或只进行了相当简单的处理，就需要考虑是否有必要使用 Decorator 模式了

Facade 模式，又称外观模式，也有人很形象地把它翻译成“门面模式”

在程序中，经常会用到其他若干个子系统。在不作任何处理的时候，需要了解每一个子系统的接口，并使用这些接口进行调用，于是系统就如图所示一样混乱。这些调用不但让结构变得混乱，客户程序和各子系统的耦合性也大大增加，扩展与维护都变得相当困难

Facade 模式通过在原有系统前增加一层的方法，封装这些子系统的接口，对外提供一致的访问接口，解决了上面的问题

Facade 模式屏蔽了子系统的细节，降低了客户程序使用这些子系统的复杂度，同时也降低了客户程序和子系统的耦合程度。这样就从需要让所有的人了解所有的子系统接口变成让个别专家抽象子系统的接口

Facade 模式很好地体现了封装的思想，它封装的是一个子系统的内部结构

在 EJB 开发领域，又根据 Facade 模式引申出 Session Facade 模式 通常使用Session Bean 封装这些业务逻辑，提高访问效率，减少内部业务逻辑和外部访问者的耦合，封装服务器中的对象模型 在 Session Facade 模式中，一般使用 Session Bean 作为业务逻辑的接口，在 SessionBean 中进行事务处理，确保客户对 SessionBean 的每一次访问即完成一次业务操作。使用Session Facade 模式除了获得 Facade 模式的优点外，还可以减少远程调用 EJB 的次数，降低网络接口的负载，提高性能

Mediator 模式，又称中介者模式

在一个复杂系统中会有很多对象，这些对象之间会相互通信，从而造成对象的相互依赖。修改其中一个对象可能会影响到其他若干对象，系统中对象的复杂耦合关系造成系统可维护性的降低，系统显得混乱且难以理解。Mediator 通过封装一组对象间的通信为系统解耦

在 Mediator 模式中，一组对象 ——抽象类 Colleague 的子类，通过中介类 —— ConcreteMediator 进行通信，中介类 ConcreteMediator 继承了抽象类 Mediator，其中需要实现 Mediator 中定义的通信接口，保证中介类和相互通信类之间接口的一致

Mediator 封装了一组对象间的通信，降低了 Colleague 之间的耦合性，单个 Colleague的变化不会影响到其他的对象

Mediator 模式在 GUI 方面有较多的使用。当一个窗体或表单或对话框中有多个需要互相通信的对象时——例如显示部门中人员的下拉列表需要根据部门下拉列表不同的选择而变化，使用 Mediator 封装通信可以降低这些对象的耦合性，提高系统的可维护性

Observer 模式，又称观察者模式

由于对象封装的特性，一般的，在系统中对象状态的变化都是独立的，即 A 对象状态的变化不会立即反映到 B 对象。但是，在系统中很多对象是相互关联的，例如对于一个股票行情系统，股票状态的变化需要同时反映到多个视图中——实时行情、技术分析图表等。对于这个问题，最简单的解决办法就是硬编码这些关联关系。但是这样会造成系统中对象的紧密耦合，系统难以维护和复用

抽象类 Subject 定义了主题类——也就是被观察者的接口，它的子类 ConcreteSubject的任何状态改变将会通知全部的观察者——ConcreteObserver。为了保持接口的一致性，这些观察者继承自相同的抽象类 Observer。 抽象类在 Subject 中保存有观察者的列表——observers，并通过 attach 和 detach 方法来动态地添加或移出一个特定的观察者。这种采用订阅方法来添加的观察者并不知道还有其他的观察者，它仅仅能够接收被观察的主题对象的状态改变。在 notify 方法中，主题类将根据目前加入订阅的观察者列表 observers 来向每一个观察者发出状态改变的消息 ConcreteSubject 中的 setState()方法表明对象的状态发生了变化，该方法会调用 notify方法对所有的观察者进行更新

在 Observer 模式中，实现了具体对象和观察者之间的抽象耦合。虽然 Subject 了解目前有哪些观察者需要捕获自己状态的变化，但它并不了解这些观察者要做什么；而每一个观察者仅仅知道自己捕获到对象的变化，但并不清楚目前有多少观察者在观察对象的状态，也不需要通知其他的观察者。这样，动态的增加和移除观察者是非常简单的

Observer 模式将一对多的对象依赖转化为抽象耦合，提高系统的复用价值，得到了广泛的应用

Intercepting Filter 模式，又称筛选器模式

在使用 MVC 架构进行 Web 应用开发时，通常需要对来自于客户的请求进行一些预处理，如验证客户身份、验证请求来源、对请求解码等，然后再传递给控制器。如果把这些预处理都交由控制器来完成，将增加控制器的复杂度，而且难以维护和扩展

FilterManager 负责调度整个 FilterChain，它将在请求到达 Target 前拦截请求，并传递给 FilterChain，由 FilterChain 中的过滤器依次进行预处理。直到请求经过最后一个过滤器后才完成了全部的预处理，然后由 FilterManger 把请求转发给实际的目标

使用 Intercepting Filter 模式使得预处理的逻辑和真正的处理逻辑分离，进行实际处理的 Target 只需要关心具体的逻辑，而同请求相关的预处理都放在 FilterManager 中进行。同时解除了这两类处理的耦合性，扩展、修改预处理过程变得容易，系统具有更好的维护性和扩展性