JAVA设计模式之工厂模式(简单工厂模式+工厂方法模式)

在面向对象编程中, 最一般的方法是一个new操做符产生一个对象实例,new操做符就是用来构造对象实例的。可是在一些状况下, new操做符直接生成对象会带来一些问题。举例来讲, 许多类型对象的创造须要一系列的步骤: 你可能须要计算或取得对象的初始设置; 选择生成哪一个子对象实例; 或在生成你须要的对象以前必须先生成一些辅助功能的对象。 在这些状况,新对象的创建就是一个 “过程”，不只是一个操做，像一部大机器中的一个齿轮传动。

 

模式的问题：你如何能轻松方便地构造对象实例，而没必要关心构造对象实例的细节和复杂过程呢？

解决方案：创建一个工厂来建立对象

实现：

1、引言
    1）尚未工厂时代：假如尚未工业革命，若是一个客户要一款宝马车,通常的作法是客户去建立一款宝马车，而后拿来用。
    2）简单工厂模式：后来出现工业革命。用户不用去建立宝马车。由于客户有一个工厂来帮他建立宝马.想要什么车，这个工厂就能够建。好比想要320i系列车。工厂就建立这个系列的车。即工厂能够建立产品。
    3）工厂方法模式时代：为了知足客户，宝马车系列愈来愈多，如320i，523i,30li等系列一个工厂没法建立全部的宝马系列。因而由单独分出来多个具体的工厂。每一个具体工厂建立一种系列。即具体工厂类只能建立一个具体产品。可是宝马工厂仍是个抽象。你须要指定某个具体的工厂才能生产车出来。

   4）抽象工厂模式时代：随着客户的要求愈来愈高，宝马车必须配置空调。因而这个工厂开始生产宝马车和须要的空调。

   最终是客户只要对宝马的销售员说：我要523i空调车，销售员就直接给他523i空调车了。而不用本身去建立523i空调车宝马车.

   这就是工厂模式。

2、分类 
        工厂模式主要是为建立对象提供过渡接口，以便将建立对象的具体过程屏蔽隔离起来，达到提升灵活性的目的。 
工厂模式能够分为三类： 

1）简单工厂模式（Simple Factory） 
2）工厂方法模式（Factory Method） 
3）抽象工厂模式（Abstract Factory） 

 这三种模式从上到下逐步抽象，而且更具通常性。 
        GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。

        将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，二者归为一类。 

3、区别 
工厂方法模式：
一个抽象产品类，能够派生出多个具体产品类。   
一个抽象工厂类，能够派生出多个具体工厂类。   
每一个具体工厂类只能建立一个具体产品类的实例。
抽象工厂模式：
多个抽象产品类，每一个抽象产品类能够派生出多个具体产品类。   
一个抽象工厂类，能够派生出多个具体工厂类。   
每一个具体工厂类能够建立多个具体产品类的实例。   
区别：
工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。   
工厂方法模式的具体工厂类只能建立一个具体产品类的实例，而抽象工厂模式能够建立多个。
二者皆可。 

 4、简单工厂模式 
创建一个工厂（一个函数或一个类方法）来制造新的对象。
分布说明引子：从无到有。客户本身建立宝马车，而后拿来用。

 

 

copy ?

 

public BMW320 {  

•      BMW320(){  
•         System.out.println( }  
•   
•   BMW523 {  
•      BMW523(){  
•         System.out.println( }  
•   
•   Customer {  
•        main(String[] args) {  
•         BMW320 bmw320 =  BMW320();  
•         BMW523 bmw523 =  BMW523();  
•     }  
• }  

客户须要知道怎么去建立一款车,客户和车就紧密耦合在一块儿了.为了下降耦合,就出现了工厂类,把建立宝马的操做细节都放到了工厂里面去,客户直接使用工厂的建立工厂方法,传入想要的宝马车型号就好了,而没必要去知道建立的细节.这就是工业革命了：简单工厂模式

即咱们创建一个工厂类方法来制造新的对象。如图：

产品类：

copy ?

 

abstract BMW {  

•      BMW(){  
•           
•     }  
• }  
•   
•   BMW320  BMW {  
•      BMW320() {  
•         System.out.println( }  
•   BMW523  BMW{  
•      BMW523(){  
•         System.out.println(    }  
• }  

工厂类：

copy ?

 

public Factory {  

•      BMW createBMW( type) {  
•          (type) {  
•           
•          :  
•               BMW320();  
•   
•          :  
•               BMW523();  
•   
•         :  
•             ;  
•         }  
•          ;  
•     }  
• }  

客户类：

copy ?

 

public Customer {  

•        main(String[] args) {  
•         Factory factory =  Factory();  
•         BMW bmw320 = factory.createBMW();  
•         BMW bmw523 = factory.createBMW();  
•     }  
• }  

   简单工厂模式又称静态工厂方法模式。重命名上就能够看出这个模式必定很简单。它存在的目的很简单：定义一个用于建立对象的接口。 
      先来看看它的组成： 
         1) 工厂类角色：这是本模式的核心，含有必定的商业逻辑和判断逻辑，用来建立产品
         2) 抽象产品角色：它通常是具体产品继承的父类或者实现的接口。         
         3) 具体产品角色：工厂类所建立的对象就是此角色的实例。在Java中由一个具体类实现。 
        
        下面咱们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当客户再也不知足现有的车型号的时候，想要一种速度快的新型车，只要这种车符合抽象产品制定的合同，那么只要通知工厂类知道就能够被客户使用了。因此对产品部分来讲，它是符合开闭原则的；可是工厂部分好像不太理想，由于每增长一种新型车，都要在工厂类中增长相应的建立业务逻辑（createBMW(int type)方法须要新增case），这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类，咱们称它为全能类或者上帝类。 
        咱们举的例子是最简单的状况，而在实际应用中，极可能产品是一个多层次的树状结构。因为简单工厂模式中只有一个工厂类来对应这些产品，因此这可能会把咱们的上帝累坏了，也累坏了咱们这些程序员。
        因而工厂方法模式做为救世主出现了。 工厂类定义成了接口,而每新增的车种类型,就增长该车种类型对应工厂类的实现,这样工厂的设计就能够扩展了,而没必要去修改原来的代码。
5、工厂方法模式 
        工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它能够被子类继承。这样在简单工厂模式里集中在工厂方法上的压力能够由工厂方法模式里不一样的工厂子类来分担。 
工厂方法模式组成： 
       1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 
       2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以建立对应的具体产品的对象。 
       3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中通常有抽象类或者接口来实现。 
       4)具体产品角色：具体工厂角色所建立的对象就是此角色的实例。在java中由具体的类来实现。 
       工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；并且这样使得结构变得灵活 起来——当有新的产品产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就能够被客户使用，而没必要去修改任何已有 的代码。能够看出工厂角色的结构也是符合开闭原则的！ 

代码以下： 

产品类：

copy ?

 

abstract BMW {  

•      BMW(){  
•           
•     }  
• }  
•   BMW320  BMW {  
•      BMW320() {  
•         System.out.println(    }  
• }  
•   BMW523  BMW{  
•      BMW523(){  
•         System.out.println( }  

建立工厂类：

copy ?

 

interface }  

•   
•   FactoryBMW320  FactoryBMW{  
•   
•       
•      BMW320 createBMW() {  
•   
•           BMW320();  
•     }  
•   
• }  
•   FactoryBMW523  FactoryBMW {  
•       
•      BMW523 createBMW() {  
•   
•           BMW523();  
•     }  
• }  

客户类：

copy ?

 

public Customer {  

•        main(String[] args) {  
•         FactoryBMW320 factoryBMW320 =  FactoryBMW320();  
•         BMW320 bmw320 = factoryBMW320.createBMW();  
•   
•         FactoryBMW523 factoryBMW523 =  FactoryBMW523();  
•         BMW523 bmw523 = factoryBMW523.createBMW();  
•     }  
• }  

 工厂方法模式仿佛已经很完美的对对象的建立进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口，但使得对象的数量成倍增加。当产品种类很是多时，会出现大量的与之对应的工厂对象，这不是咱们所但愿的。

以上就是简单工厂模式，工厂方法模式，抽象工厂模式在这里。

 

例子背景：

随着客户的要求愈来愈高，宝马车须要不一样配置的空调和发动机等配件。因而这个工厂开始生产空调和发动机，用来组装汽车。这时候工厂有两个系列的产品:空调和发动机。宝马320系列配置A型号空调和A型号发动机，宝马230系列配置B型号空调和B型号发动机。

概念：

   抽象工厂模式是工厂方法模式的升级版本，他用来建立一组相关或者相互依赖的对象。好比宝马320系列使用空调型号A和发动机型号A，而宝马230系列使用空调型号B和发动机型号B，那么使用抽象工厂模式，在为320系列生产相关配件时，就无需制定配件的型号，它会自动根据车型生产对应的配件型号A。

针对百度百科上对于抽象工厂模式的简介，结合本例以下：

当每一个抽象产品都有多于一个的具体子类的时候（空调有型号A和B两种，发动机也有型号A和B两种），工厂角色怎么知道实例化哪个子类呢？好比每一个抽象产品角色都有两个具体产品（产品空调有两个具体产品空调A和空调B）。抽象工厂模式提供两个具体工厂角色（宝马320系列工厂和宝马230系列工厂），分别对应于这两个具体产品角色，每个具体工厂角色只负责某一个产品角色的实例化。每个具体工厂类只负责建立抽象产品的某一个具体子类的实例。

抽象工厂模式代码

 产品类： 

copy ?

 

//发动机以及型号   public Engine {    

•   
• }    
•   EngineA  Engine{    
•      EngineA(){    
•         System.out.println( }    
•   EngineBextends Engine{    
•      EngineB(){    
•         System.out.println(    }    
• }    
•   
•   
•   Aircondition {    
•   
• }    
•   AirconditionA  Aircondition{    
•      AirconditionA(){    
•         System.out.println(    }    
• }    
•   AirconditionB  Aircondition{    
•      AirconditionB(){    
•         System.out.println( }   

建立工厂类：

 

copy ?

 

//建立工厂的接口   public AbstractFactory {    

•       
•      Engine createEngine();  
•       
•      Aircondition createAircondition();   
• }    
•   
•   
•   
•   FactoryBMW320  AbstractFactory{    
•         
•         
•      Engine createEngine() {      
•           EngineA();    
•     }    
•         
•      Aircondition createAircondition() {    
•           AirconditionA();    
•     }    
• }    
•   
•   FactoryBMW523  AbstractFactory {    
•     
•          
•      Engine createEngine() {      
•           EngineB();    
•     }    
•         
•      Aircondition createAircondition() {    
•           AirconditionB();    
•     }    
•   
•   
• }   

 

客户:

 

copy ?

 

public Customer {    

•        main(String[] args){    
•           
•         FactoryBMW320 factoryBMW320 =  FactoryBMW320();    
•         factoryBMW320.createEngine();  
•         factoryBMW320.createAircondition();  
•             
•           
•         FactoryBMW523 factoryBMW523 =  FactoryBMW523();    
•         factoryBMW320.createEngine();  
•         factoryBMW320.createAircondition();  
•     }    
• }  

关于抽象工厂模式与工厂方法模式的区别，这里就不说了，感受多看几遍例子就能理解，还有不少提到的产品族、等级结构等概念，说了反而更难理解。

抽象工厂模式的起源

下面引用一段 抽象工厂模式的起源：

抽象工厂模式的起源或者最先的应用，是用于建立分属于不一样操做系统的视窗构建。好比：命令按键（Button）与文字框（Text)都是视窗构建，在UNIX操做系统的视窗环境和Windows操做系统的视窗环境中，这两个构建有不一样的本地实现，它们的细节有所不一样。

在每个操做系统中，都有一个视窗构建组成的构建家族。在这里就是Button和Text组成的产品族。而每个视窗构件都构成本身的等级结构，由一个抽象角色给出抽象的功能描述，而由具体子类给出不一样操做系统下的具体实现。

能够发如今上面的产品类图中，有两个产品的等级结构，分别是Button等级结构和Text等级结构。同时有两个产品族，也就是UNIX产品族和Windows产品族。UNIX产品族由UNIX Button和UNIX Text产品构成；而Windows产品族由Windows Button和Windows Text产品构成。

系统对产品对象的建立需求由一个工程的等级结构知足，其中有两个具体工程角色，即UnixFactory和WindowsFactory。UnixFactory对象负责建立Unix产品族中的产品，而WindowsFactory对象负责建立Windows产品族中的产品。这就是抽象工厂模式的应用，抽象工厂模式的解决方案以下图：

显然，一个系统只可以在某一个操做系统的视窗环境下运行，而不能同时在不一样的操做系统上运行。因此，系统实际上只能消费属于同一个产品族的产品。

在现代的应用中，抽象工厂模式的使用范围已经大大扩大了，再也不要求系统只能消费某一个产品族了。

总结：

不管是简单工厂模式，工厂方法模式，仍是抽象工厂模式，他们都属于工厂模式，在形式和特色上也是极为类似的，他们的最终目的都是为了解耦。在使用时，咱们没必要去在乎这个模式到底工厂方法模式仍是抽象工厂模式，由于他们之间的演变经常是使人琢磨不透的。常常你会发现，明明使用的工厂方法模式，当新需求来临，稍加修改，加入了一个新方法后，因为类中的产品构成了不一样等级结构中的产品族，它就变成抽象工厂模式了；而对于抽象工厂模式，当减小一个方法使的提供的产品再也不构成产品族以后，它就演变成了工厂方法模式。

       因此，在使用工厂模式时，只须要关心下降耦合度的目的是否达到了

博客：http://blog.csdn.net/jason0539（转载请说明出处）