LorDong's Blog

意图：定义一个用于创建对象的接口，让子类决定实现化哪一个类。将实例化推迟到子类。

问题：一个类需要实例化另一个类的派生类，但不知道是哪一个。Factory Method允许派生类进行决策。

解决方案：派生类对实例化哪个类和如何实例化做出决策。

参考者与协作者：Product是工厂方法所创建的对象类型的接口。Creator是定义工厂方法的接口。

效果：客户将需要派生Creator，以创建一个特定的ConcreteProduct对象。

实现：在抽象类中使用一个抽象方法（即C++的纯虚函数）。需要实例化一个被包含对象的时候抽象类的代码将引用此方法，但是不知道需要的对象是哪一个。

（更多…）

意图：在创建对象比较昂贵，或者对于特定类型能够创建的对象数目有限制时，管理对象的重用。（比如数据库连接）

问题：对象的创建和/或管理必须遵循一组定义明确的规则集。通常这些规则都与如何创建对象、能够创建多少个对象和在已有对象完成当前任务时如何重用它们等等相关。

解决方案：在需要一个Reusable对象时， Client调用ReusablePool的acquireReusable方法。如果池是空的，那么acquireReusable方法创建一个Reusable对象（如果能够），否则，就等待直到有Reusable对象返回集合。

参与者与协作者：ReusablePool管理着Client所用的Reusable对象的可用性。Client然后在一个有限的时间段内使用Reusable对象的实例，ReusablePool包含所有Reusable对象，这样就可以对其以统一的方式进行管理。

效果：最适用于对对象的需求一直非常稳定的时候，需求变化太大会带来性能问题。ObjectPool中为了解决这一问题，限制了能够创建的对象数量。使管理实例创建的逻辑与实例被管理的类分离，可以得到内聚更好的设计。

实现：如果可以创建的对象数量有限制，或者池的大小有限制，可以使用一个简单的数组来实现池。否则，使用vector对象，负责管理对象池的对象必须惟一能够创建这些对象的对象。ReusablePool是用Singleton模式实现的。另一种变体是在Reusable对象中加一个释放方法——让它自己返回到池。

（更多…）

意图：希望对象只有一个实例，但没有控制对象实现代的全局对象。还希望确保所有实体使用该对象相同的实例，而无需将引用传给它们。

问题：几个不同的客户对象需要引用同一个对象，而且希望确保这种类型的对象数目不超过一个。

解决方案：保证一个实例。

参与者与协作者：Client对象只能通过getInstance方法创建Singleton实例。

效果：Client对象无需操心是否存在Singleton实例。这是由Singleton自己控制的。

实现：
1. 添加一个类的私有的静态成员变量，引用所需的对象（初值为null）。
2. 添加一个公共静态方法，它在成员变量为null时实例化这个类（并设置成员变量的值），然后返回该成员变量的值。
3. 将构造函数的状态设置为保护或私有，从而防止任何人直接实例化这个类，绕过静态构造函数机制。

（更多…）

意图：定义一个操作中算法的骨架，将一些步骤推迟到子类实现。可以不改变算法的结构而重定义该算法的步骤。

问题：要完成要某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同。

解决方案：允许定义可变的子步骤，同时保持基本过程一致。

参与者与协作者：Template Method模式由一个抽象类组成，这个抽象类定义了需要覆盖的基本TemplateMethod方法。每个从这个抽象类派生的具体类将为此模板实现新方法。

效果：模板提供了一个很好的代码复用平台。它还有助于确保所需步骤的实现。它将每个Concrete类的覆盖步骤绑定起来，因此只有在这些变化总是并且只能一起发生时，才应该使用Template Method模式。

实现：创建一个抽象类，用抽象方法实现一个过程。这些抽象方法必须在子类中实现，以执行过程的每个步骤。如果这些步骤是独立变化的，那么每个步骤都可以用Strategy模式来实现。

（更多…）

意图：在对象之间定义一种一对多的依赖关系，这样当一个对象的状态改变时，所有依赖者都将得到通知并自动更新。

问题：当某个事件发生时，需要向一系列变化着的对象发出通知。

解决方案：Observer将监视某个事件的责任委托给中心对象：Subject。

参与者与协作者：Subject知道自己的Observer，因为Observer要向它注册。Subject必须在所监视的事件发生时通知Observer。Observer负责向Subject注册，以及在得到通知时从Subject处获取信息。

效果：如果某些Observer只对事件的一个子集感兴趣，那么Subject可能会告诉它们不需要知道的事件。如果Subject通知Observer，Observer还返回请示更多信息，则可能需要额外的通信。

实现：让某个事件发生时需要知道的对象（Observer）将自己注册到另一个监视事件发生或自己触发事件的对象（Subject）上。事件发生时，Subject告诉Observer事件已经发生。为了对所有Observer类型的对象实现Observer接口，有时候需要使用Adapter模式。

（更多…）

意图：动态地给一个对象添加职责。

问题：要使用的对象执行所需的基本功能。但是，可能需要为这个对象将添加某些功能，这些附加功能可能发生在对象的基础功能之前或之后。

解决方案：可以无需创建子类，而扩展一个对象的功能。

参与者与协作者：ConcreteComponent让Decorator对象为自己添加功能。有时候用ConcreteComponent的派生类提供核心功能，在这种情况下ConcreteComponent类就不再是具体的，而是抽象的。Component类定义了所有这些所使用的接口。

效果：所添加的功能放在小对象中。好处是可以在ConcreteComponent对象的功能之前或之后动态添加功能。注意，虽然装饰对象可以在被装饰对象之前或之后添加功能，但对象链总是终于ConcreteComponent对象。

实现：创建一个抽象类来表示原类和要添加到这个类的新功能。在装饰类中，将对新功能的调用放在对紧随其后对象的调用之前或之后，以获得正确的顺序。

（更多…）

意图：需要为特定的客户（或情况）提供对象组。

问题：需要实例化一组相关的对象。

解决方法：协调对象组的创建。提供一种方式，将如何执行对象实例化的规则从使用这些对象的客户对象提取出来。

参与者与协作者：AbstractFactory为如何创建对象组的每个成员定义接口。一般每个组都由独立的ConcreteFactory进行创建。

效果：这个模式将“使用哪些对象”的规则与“如何使用这些对象”的逻辑分离开来。

实现：定义一个抽象类来指定创建哪些对象。然后为每个组实现一个具体类。可以用表或文件完成同样的任务。

（更多…）

意图：将一组实现与另一组使用它们的对象分离。

问题：一个抽象类的派生类必须使用多个实现，但不能出现类数量爆炸性增长。

解决方案：为所有实现定义一个接口，供抽象类的所有派生类使用。

参与者与协作者：Abstraction为要实现的对象定义接口，Implementor为具体的实现类定义接口。Abstraction的派生类使用Implementor的派生类，却无需知道自己具体使用哪一个ConcreteImplementor。

效果：实现与使用的对象解耦，提供了可扩展性，客户对象无需操心实现问题。

实现：
1. 将实现封装在一个抽象类中。
2. 在要实现的抽象的基类中包含一个实现的句柄。

（更多…）

意图：可以根据所处上下文，使用不同的业务规则或算法。

问题：对所需算法的选择取决于发出请求的客户或者要处理的数据。如果只有一些不会变化的算法，就不需要Strategy模式。

解决方案：将对算法的选择和算法的实现相分离。允许根据上下文进行选择。

参与者与协作者：
1. Strategy指定了如何使用不同的算法。
2. 各ConcreteStrategy实现了这些不同的算法。
3. Context通过类型为Strategy的引用使用具体的ConcreteStrategy。Strategy与Context相互作用以实现所选的算法（有时候Strategy必须查询Context）。Context将来自Client的请求转发给Strategy。

（更多…）

意图：使控制范围之外的一个原有对象与某个接口匹配。

问题：系统的数据和行为都正确，但接口不符。通常用于必须从抽象类派生时。

解决方案：Adapter模式提供了具有所需接口的包装类。

参与者与协作者：Adapter改变了Adaptee的接口，使Adaptee与Adapter的基类Target匹配。这样Client就可以使用Adaptee了，好象它是Target类型。

效果：Adapter模式使原有对象能够适应新的类结构，不受其接口的限制。

实现：将原有类包含在另一个类之中。让包含类与需要的接口匹配，调用被包容类的方法。

（更多…）