设计模式学习整理（一）

工厂模式

工厂模式在《Java与模式》中分为三类：  

    1）简单工厂模式（Simple Factory）

    2）工厂方法模式（Factory Method）

    3）抽象工厂模式（Abstract Factory）

简单工厂模式

简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。      

它的组成：

1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由

一个具体类实现。

2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽

象类来实现。

3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。

工厂方法模式  

工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。

它的组成：

1) 抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须

实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。

2) 具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体

产品的对象。

3) 抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类

或者接口来实现。

4) 具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类

来实现。

工厂方法模式仿佛已经很完美的对对象的创建进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢？大可不必。也许在下面情况下你可以考虑使用工厂方法模式：

1) 当客户程序不需要知道要使用对象的创建过程。

2) 客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。  

简单工厂模式与工厂方法模式真正的避免了代码的改动了？没有。在简单工厂模式中，新产品的加入要修改工厂角色中的判断语句；而在工厂方法模式中，要么将判断逻辑留在抽象工厂角色中，要么在客户程序中将具体工厂角色写死（就象上面的例子一样）。而且产品对象创建条件的改变必然会引起工厂角色的修改。  面对这种情况，Java的反射机制与配置文件的巧妙结合突破了限制――这在Spring中完美的体现了出来。

抽象工厂模式

抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象 而且使用抽象工厂模式还要满足一下条件：

1) 系统中有多个产品族，而系统一次只可能消费其中一族产品。 2) 同属于同一个产品族的产品以其使用。

来看看抽象工厂模式的各个角色（和工厂方法的如出一辙）：

1) 抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须

实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 2) 具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体

产品的对象。在java中它由具体的类来实现。

3) 抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类

或者接口来实现。

4) 具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类

来实现。