Factory模式

       Factory Mathod模式是应用最广泛的设计模式，毕竟它负责的是一系列对象的创建，而对象的创建正是面向对象编程中最频繁的行为。

       在面向对象设计中，对象的管理是核心所在，管理的第一步创建是十分简单的。在C++中，只需要使用new操作符调用对象的构造函数就可以了。但是这样的创建过程使创建者与被创建者之间耦合度增强。举个例子：

Class shape

{

};

Class circle:public shape

{

};

Class square:public shape

{

};

这几个对象，其中能创建实例的类只有circle、square，而shape是作为抽象类或者是接口使用。那么创建对象时，就应该这样调用。Shape shape1=new circle();或者是shape shape1=new square();当多个模块需要这类对象时就会大量的出现这样的代码，耦合度增强。而且，当需要把square类型改为Triangle类型时，在这样的状态下，我们只能够一个一个进行修改。

因为这样的种种原因，必须引入新的方法，它需要封装变化，它就是工厂模式。工厂模式就是为每一个类，都对应上其生产的工厂。也就是说，shape类型的对象都是由工厂生产的产品。工厂对象的结构应与产品对象的结构平行。

按照刚才的代码，将其扩展成为工厂模式。

Class shapeFactory

{

       Public:

              virtual Shape Createshape()=0;

};

Class circleFactory:public shapeFactory

{

       Public:

              Shape Createshape()

{

       Return new circle();

}

};

Class squareFactory:public shapeFactory
{

       Public:

              Shape Createshape()

{

       Return new square();

}

};

       经过这样的变化，我们只需要在一个统一的模块中创建想要的工厂对象。然后再通过这些工厂对象创建对应的产品。像下面这样：

shapeFactory m_pshapeFactory=new squareFactory();

 

shape m_pshape=m_pshapeFacetory.Createshape();

       这样，我们就可以在square需要变化时，不用一发而动全身。只需要修改 squareFactory就可以了。程序中不会在不同模块中出现大量的new的重复代码。解除了创建者与被创建对象的耦合度。

       事实上，工厂模式只不过是将对象的创建延迟到工厂类上。所谓智者千虑必有一失，这样做也带入了另外一个问题，就是调用者与产品之间的耦合度问题。但是，这个问题也得到了很好的解决，利用一个静态的创建函数，同时引入一个注册的映射关系，这个映射关系可以应对未来的扩展，能够巧妙的解开具体工厂类、产品类与调用者之间的耦合关系。也就是说当引入新的类型访问时，只需要修改它所属接口的那一个模块及工厂模块。当使用时，只需要将其注册到一个类型缓冲中去，然后就能通过静态函数创建这个产品。

代码类似以下：

shape.Register(“xxx”,new XXXshapeFactoryCreator())

以下是本人见解:

    本人觉得.net framework 增加了这个注册方法,也只是将耦合度延迟到另外一种关系上,同时也因为添加了大量的代码,使程序的速度变慢.因此,我认为只需要添加工厂类,然后集中一个模块创建工厂类对象就可以了.不需要在增加注册方法,因为就算增加注册方法,也需要每当遇到新扩展时,都要修改工厂类与产品类.