设计模式笔记(2 FACTORY METHOD)

FACTORY METHOD(工厂方法)
理解:
一个类需要创建某个类的实例,但是,又不知道(或者不该知道)如何创建实例时,需要工厂方法.例如一个TEMPLETE METHOD中,创建各种新实例(比如,各种文档),那么需要提供一个单一的创建接口,而将创建的实现分离出去,这种分离的创建行为,就是工厂模式.
很显然,所有的创建行为,都必须提供共同的接口,创建的产品,也必须具有共同接口.这一点和抽象类厂是不一样的.抽象类厂具有一组创建接口,用来创建一个产品系列中的一个对象,一般而言,抽象类厂创建的一组实例实际上也是同一系列中的不同对象.而从上层来看,类厂则创建的是单一对象类型(共同接口).

在书中的适用性中提到:
类厂的另一个应用是希望由它的子类来指定它所创建的对象的时候.在这一应用中,子类必须知道如何创建对象,并且实际创建对象.也就是说,子类和具体被创建的类是绑定的.特定的子类,创建确定的对象:
class Base {
public:
    virtual Product* create() = 0;
};
class DeriveA : public Base{
public:
    virtual Product* create() { return ProductA;}
};
实际上,这种方法和前一小结提到的单一创建接口而言,是将创建方法的实现放到类厂的类族当中去.他并没有将创建活动本身独立出来.这样的好处是简单,很多时候也足够使用,创建过程可以更加灵活,更加强大.缺点是,类厂的子类和具体被创建类之间是紧密耦合的.然而,创建过程通过运用创建策略,也可以达到高度的灵活性,这可以结合了策略模式.

再来看第一部分的思路.
既然创建活动本身需要一个统一的创建接口(第二部分的创建接口也是统一的),并且可以独立出来,如果有大量的创建过程,那么这些创建过程往往需要组织起来.参数化类厂正是这一模式的具体运用.为每个具体类指定一个唯一的标识
然后,可以通过维护一个字典表,保存标识到创建方法的映射.那么就可以通过参数来确定我们实际上创建的是什么具体类,类厂本身只是需要根据参数找到创建过程,再获取创建过程的结果就可以了.这种方法具有很好的灵活性,一旦了解了其工作机制,实现上的复杂性也是可以理解的.
现在剩下的工作就是要维护这张映射表了,这是一个烦琐的簿记工作.Loki.Factory提供了一个非常灵活的参数化类厂的实现.先看一下定义
template
    <
        class AbstractProduct,
        typename IdentifierType,
        typename ProductCreator = AbstractProduct* (*)(),
        template<typename, class>
            class FactoryErrorPolicy = DefaultFactoryError
    >
    class Factory
        : public FactoryErrorPolicy<IdentifierType, AbstractProduct>
    {...
public:
        bool Register(const IdentifierType& id, ProductCreator creator)
...
    AbstractProduct* CreateObject(const IdentifierType& id)

通过Register,简化了簿记工作.创建方法则是一目了然的了.
等等...,谁来调用Register?一个方法是,在系统启动之初,写一串代码,来调用Register,但是,这样明显不方便:每增加一个具体类,就需要修改这段代码.其次,Register的地方,需要知道所有的具体类,这时极为不方便的.
一个不错的做法是,为Factory提供一个单件的实现,然后,利用局部静态对象的构造函数,完成注册过程.通常,IdentifierType可以选择字符串,而ProductCreator选择Functor来实现更容易一些,当然,代码可能需要一点点微不足道的技巧^_^