工厂模式

 

Factory 模式负责将大量有共同接口的类实例化，Factory模式可以动态的决定哪一个类实例化。Factory模式可以分为三种：

1）  Simple Factory 模式（Static Factory Method）模式。

2）  Factory Method模式 （Polymorphic Factory）多态工厂模式或（Virtural Constructor）虚拟构造子模式。

3）  抽象工厂（Abstract Factory）模式 （Kit /ToolKit）工具箱模式。

简单工厂模式(Simple Factory)

简单的工厂模式是类的创建模式，又叫做静态工厂方法（Static Factory Method）模式，

simpleFactory是由一个工厂对象决定创建出那一种产品类的实例。

Simple Factory的神话实例就是女娲篆人。

Simple Factory模式涉及到三个角色：工厂角色、抽象产品角色、具体产品角色。

工厂角色：（creator）

       含有与具体应用有关的商业逻辑。工厂类在客户端的直接调用下创建产品对象。

抽象产品角色：（product）

       担任这个角色的类是工厂创建对象的父类，或他们有共同的接口。

具体产品角色：（Concrete product）

       工厂方法所创建的任何对象都是这个角色的实例。

Simple Factory在java中的应用是java.text.DateFormat 等。

缺点：没有扩展性。对“开－闭”原则支持不够。

 

工厂方法模式(Factory Method)

使用了多态性，保留了simple Factory的优点。克服了缺点。

在Factory Method中，核心工厂类不再负责所有产品的创建，具体的创建工作交给了子类去做，成为抽象工厂的角色。仅负责给出具体工厂子类必须实现的接口。

工厂方法模式的系统涉及到下面几个角色：

抽象工厂（Creator）：任何在模式中创建对象的工厂类必须实现这个接口，实际中这个类往往有抽象的java类来实现。

具体工厂（Concrete Creator）：实现了抽象工厂接口的具体的类，与应用系统密切相关，受到应用程序的调用以创建产品对象。

抽象产品（Product）：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口，在实际系统中，有抽象的java类来实现。

具体产品（Concrete Product）：实现了抽象产品角色所声明的接口，工厂方法模式所创建的每一个对象都是某一个具体产品角色的实例。

 

如果系统增加一个新的产品，则只增加这个产品的类以及他的工厂类，没有必要修改其他的类，从而完全支持“开－闭”原则。

 

抽象工厂角色和抽象产品角色都可以用java接口和抽象类来实现。

如果具体的工厂角色都有共同的逻辑，那么这些共同的逻辑就可以向上移动到抽象的工厂角色中，这就意味着抽象工厂角色应该有一个java抽象类来实现。并由这个抽象工厂提供默认的方法。

工厂方法不一定每次都返回一个新的对象，但是每个对象一定是他自己建的，而不是外部创建的对象传人工厂里面去的。

工厂方法所返回的是抽象类型，而不是具体的类型，保证了产品的多态性。

 

在java类库中的应用：

1、多个对象聚集在一起的总体称为聚集。聚集对象是一个能够包容一组对象的容器对象。比如vector arraylist等，都实现了java.util.Collection接口，这个接口规定了所有的聚集都提供一个iterator()方法，返回一个Iterator类型的对象。

Iterator（）就是一个工厂方法。

抽象工厂模式(Abstract Factory)

抽象工厂模式和工厂方法模式的最大区别在于工厂方法模式针对的是一个产品等级的结构，而抽象工厂模式则需要面对多个产品等级结构。

 

抽象工厂中的角色|:

       抽象工厂(AbstractFactory)角色:这个角色是工厂方法模式的核心.他是与应用系统的商业逻辑无关的,通常使用java接口或抽象类来实现.而所有的具体工厂类必须实现这个java接口或继承这个抽象类.

       具体工厂类(ConreteFactory)角色:这个角色直接在客户端调用下创建产品的实例.这个角色含有选择合适的产品对象的逻辑.这个逻辑与应用系统的商业逻辑有具体的关系.

       抽象产品(AbstractProduct)角色:担任这个角色的类是工厂方法所产生对象的父类,或他们拥有共同的接口,这个通常是java接口或抽象类来实现.

       具体产品类(ConreteProduct)角色:抽象工厂模式所创建的任何产品对象都是某个具体产品类的实例.这个是客户端最终的东西.其内部一定充满了应用系统的商业逻辑.