设计模式之工厂模式
一、工厂模式的认识
工厂模式是我们最常用的实例化对象模式了，是用工厂方法代替new操作的一种
模式。著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说
是随处可见。因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class
生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new
时就要多个心眼，是否可以考虑使用工厂模式，虽然这样做，可能多做一些工作，但会
给你系统带来更大的可扩展性和尽量少的修改量。
工厂模式包括简单工厂方法、工厂方法模式和抽象工厂模式；其中抽象工厂模式是
工厂方法模式的扩展。
二、工厂模式的意图
1、定义一个接口来创建对象，但是让子类来确定哪些类需要被实例化。
2、工厂方法把实例化的工作推迟到子类中去实现。
三、工厂模式的应用场景
1、适合工厂模式的情况
1、有一组类似的对象需要创建。
2、在编码时不能预见需要创建哪种类的实例。
3、系统需要考虑扩展性，不应依赖于产品类实例如何被创建、组合和表达的细节。
2、工厂模式使用的动机
项目中的现状：在软件系统中经常面临着“对象”的创建工作，由于需求的变化，
这个对象随之也会发生变化，但它却拥有着比较稳定的接口。为此，我们需要提供一种
封装机制来隔离出这个易变对象的变化，从而保持系统中其他依赖该对象的对象不随着
需求变化而变化。 那么，工厂设计模式就是用来帮助你new对象的。为什么不直接
new对象，而是通过工厂模式呢？避免直接对对象进行创建，而且把所有的对象都集
中起来管理，也可以在不改动应用程序的基础上直接添加对象，便于对象的维护。
基于项目现状将代码进行如下设计：
1、尽量松耦合，一个对象的依赖对象的变化与本身无关。
2、具体产品与客户端剥离，责任分割。
四、工厂模式的设计思想
1、简单工厂方法
简单工厂模式（Simple FactoryPattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethodPattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
简单工厂模式中包含的角色及其相应的职责如下：
工厂角色（Creator）：这是简单工厂模式的核心，由它负责创建所有的类的内部逻辑。当然工厂类必须能够被外界调用，创建所需要的产品对象。
抽象（Product）产品角色：简单工厂模式所创建的所有对象的父类，注意，这里的父类可以是接口也可以是抽象类，它负责描述所有实例所共有的公共接口。
具体产品（Concrete Product）角色：简单工厂所创建的具体实例对象，这些具体的产品往往都拥有共同的父类。
简单工厂模式的UML图：
简单工厂模式深入分析：简单工厂模式解决的问题是如何去实例化一个合适的对象。
简单工厂模式的核心思想就是：有一个专门的类来负责创建实例的过程。
具体来说，把产品看着是一系列的类的集合，这些类是由某个抽象类或者接口派生出来的一个对象树。而工厂类用来产生一个合适的对象来满足客户的要求。
如果简单工厂模式所涉及到的具体产品之间没有共同的逻辑，那么我们就可以使用接口来扮演抽象产品的角色；如果具体产品之间有功能的逻辑或，我们就必须把这些共同的东西提取出来，放在一个抽象类中，然后让具体产品继承抽象类。为实现更好复用的目的，共同的东西总是应该抽象出来的。
在实际的的使用中，抽闲产品和具体产品之间往往是多层次的产品结构，如下图所示：
简单工厂模式使用场景分析及代码实现：
GG请自己的女朋友和众多美女吃饭，但是GG自己是不会做饭的或者做的饭很不好，这说明GG不用自己去创建各种食物的对象；各个美女都有各自的爱好，到麦当劳后她们喜欢吃什么直接去点就行了，麦当劳就是生产各种食物的工厂，这时候GG不用自己动手，也可以请这么多美女吃饭，所要做的就是买单，其UML图如下所示：
实现代码如下：
新建立一个食物的接口：
package com.diermeng.designPattern.SimpleFactory;
/*
* 产品的抽象接口
*/
public interface Food {
/*
* 获得相应的食物
*/
public void get();
}
接下来建立具体的产品：麦香鸡和薯条
package com.diermeng.designPattern.SimpleFactory.impl;
import com.diermeng.designPattern.SimpleFactory.Food;
/*
* 麦香鸡对抽象产品接口的实现
*/
public class McChicken implements Food{
/*
* 获取一份麦香鸡
*/
public void get(){
System.out.println("我要一份麦香鸡");
}
}
package com.diermeng.designPattern.SimpleFactory.impl;
import com.diermeng.designPattern.SimpleFactory.Food;
/*
* 薯条对抽象产品接口的实现
*/
public class Chips implements Food{
/*
* 获取一份薯条
*/
public void get(){
System.out.println("我要一份薯条");
}
}
现在建立一个食物加工工厂：
package com.diermeng.designPattern.SimpleFactory.impl;
import com.diermeng.designPattern.SimpleFactory.Food;
public class FoodFactory {
public static Food getFood(String type) throws InstantiationException,IllegalAccessException, ClassNotFoundException {
if(type.equalsIgnoreCase("mcchicken")){
return McChicken.class.newInstance();
} else if(type.equalsIgnoreCase("chips")){
return Chips.class.newInstance();
} else {
System.out.println("哎呀！找不到相应的实例化类啦！");
return null;
}
}
}
最后我们建立测试客户端：
package com.diermeng.designPattern.SimpleFactory.client;
import com.diermeng.designPattern.SimpleFactory.Food;
import com.diermeng.designPattern.SimpleFactory.impl.FoodFactory;
/*
* 测试客户端
*/
public class SimpleFactoryTest {
public static void main(String[]args) throws InstantiationException,IllegalAccessException, ClassNotFoundException {
//实例化各种食物
Food mcChicken = FoodFactory.getFood("McChicken");
Food chips = FoodFactory.getFood("Chips");
Food eggs = FoodFactory.getFood("Eggs");
//获取食物
if(mcChicken!=null){
mcChicken.get();
}
if(chips!=null){
chips.get();
}
if(eggs!=null){
eggs.get();
}
}
}
输出的结果如下：
| 哎呀！找不到相应的实例化类啦！ 我要一份麦香鸡 我要一份薯条 |
简单工厂模式的优缺点分析：
优点：工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。
缺点：由于工厂类集中了所有实例的创建逻辑，这就直接导致一旦这个工厂出了问题，所有的客户端都会受到牵连；而且由于简单工厂模式的产品室基于一个共同的抽象类或者接口，这样一来，但产品的种类增加的时候，即有不同的产品接口或者抽象类的时候，工厂类就需要判断何时创建何种种类的产品，这就和创建何种种类产品的产品相互混淆在了一起，违背了单一职责，导致系统丧失灵活性和可维护性。而且更重要的是，简单工厂模式违背了“开放封闭原则”，就是违背了“系统对扩展开放，对修改关闭”的原则，因为当我新增加一个产品的时候必须修改工厂类，相应的工厂类就需要重新编译一遍。
总结一下：简单工厂模式分离产品的创建者和消费者，有利于软件系统结构的优化；但是由于一切逻辑都集中在一个工厂类中，导致了没有很高的内聚性，同时也违背了“开放封闭原则”。另外，简单工厂模式的方法一般都是静态的，而静态工厂方法是无法让子类继承的，因此，简单工厂模式无法形成基于基类的继承树结构。
2、工厂方法模式
通过工厂方法模式的类图可以看到，工厂方法模式有四个要素：
1、工厂接口。工厂接口是工厂方法模式的核心，与调用者直接交互用来提供产品。在实际编程中，有时候也会使用一个抽象类来作为与调用者交互的接口，其本质上是一样的。
2、工厂实现。在编程中，工厂实现决定如何实例化产品，是实现扩展的途径，需要有多少种产品，就需要有多少个具体的工厂实现。
3、产品接口。产品接口的主要目的是定义产品的规范，所有的产品实现都必须遵循产品接口定义的规范。产品接口是调用者最为关心的，产品接口定义的优劣直接决定了调用者代码的稳定性。同样，产品接口也可以用抽象类来代替，但要注意最好不要违反里氏替换原则。
4、产品实现。实现产品接口的具体类，决定了产品在客户端中的具体行为。
工厂方法模式代码如下：
[java] view plain copy
interface IProduct {
public void productMethod();
}
class Product implements IProduct {
public void productMethod() {
System.out.println("产品");
}
}
interface IFactory {
public IProduct createProduct();
}
class Factory implements IFactory {
public IProduct createProduct() {
return new Product();
}
}
public class Client {
public static void main(String[] args) {
IFactory factory = new Factory();
IProduct prodect = factory.createProduct();
prodect.productMethod();
}
}
典型应用：要说明工厂模式的优点，可能没有比组装汽车更合适的例子了。场景是这样的：汽车由发动机、轮、底盘组成，现在需要组装一辆车交给调用者。假如不使用工厂模式，代码如下：
[java] view plain copy
class Engine {
public void getStyle(){
System.out.println("这是汽车的发动机");
}
}
class Underpan {
public void getStyle(){
System.out.println("这是汽车的底盘");
}
}
class Wheel {
public void getStyle(){
System.out.println("这是汽车的轮胎");
}
}
public class Client {
public static void main(String[] args) {
Engine engine = new Engine();
Underpan underpan = new Underpan();
Wheel wheel = new Wheel();
ICar car = new Car(underpan, wheel, engine);
car.show();
}
}
可以看到，调用者为了组装汽车还需要另外实例化发动机、底盘和轮胎，而这些汽车的组件是与调用者无关的，严重违反了迪米特法则，耦合度太高。并且非常不利于扩展。另外，本例中发动机、底盘和轮胎还是比较具体的，在实际应用中，可能这些产品的组件也都是抽象的，调用者根本不知道怎样组装产品。假如使用工厂方法的话，整个架构就显得清晰了许多。
interface IFactory {
public ICar createCar();
}
class Factory implements IFactory {
public ICar createCar() {
Engine engine = new Engine();
Underpan underpan = new Underpan();
Wheel wheel = new Wheel();
ICar car = new Car(underpan, wheel, engine);
return car;
}
}
public class Client {
public static void main(String[] args) {
IFactory factory = new Factory();
ICar car = factory.createCar();
car.show();
}
}
使用工厂方法后，调用端的耦合度大大降低了。并且对于工厂来说，是可以扩展的，以后如果想组装其他的汽车，只需要再增加一个工厂类的实现就可以。无论是灵活性还是稳定性都得到了极大的提高。
3、抽象工厂模式
抽象工厂模式（Abstract Factory）：为创建一组相关或者互相依赖的对象提供一个接口，而无需指定它们对应的具体类。通用类图如下：
例如，我们现在有两种产品A和B，而产品A和B分别都有两个厂商1和2进行生产，在这里我们把不同的厂商1、厂商2理解为牌子1和牌子2，那么厂商1就生产A1、B1，厂商2生产A2、B2。
此时，不同的厂商肯定要生产自己的产品（如A1、B1），每个厂商都有自己的一系列产品，这就与上面抽象工厂模式的描述类似了。
该例子的类图如下：
具体代码实现如下：
//定义不同的产品之间的一定具备的标准，用interface实现
//其中的method()方法可看作提取出不同产品的共性，如手机都有类似的功能
interface IProductA{
public void method();
}
interface IProductB{
public void method();
}
//实现了产品标准实现的一系列具体产品
//由于已经设计好A1由厂商1生产，故以下输出代码有“厂商x”
class ProductA1 implements IProductA{
public void method() {
System.out.println("厂商1 生产ProductA1...");
}
}
class ProductA2 implements IProductA{
public void method() {
System.out.println("厂商2 生产ProductA2...");
}
}
class ProductB1 implements IProductB{
public void method() {
System.out.println("厂商1 生产ProductB1...");
}
}
class ProductB2 implements IProductB{
public void method() {
System.out.println("厂商2 生产ProductB2...");
}
}
//每一种牌子的产品生产工厂，即不同的厂商负责自己牌子产品的生产
abstract class Factory1{
abstract IProductA getProductA1();
abstract IProductB getProductB1();
}
abstract class Factory2{
abstract IProductA getProductA2();
abstract IProductB getProductB2();
}
//具体的工厂用来生产相关的产品
class ConcreteFactory1 extends Factory1{
public IProductA getProductA1() {
return new ProductA1();
}
public IProductB getProductB1() {
return new ProductB1();
}
}
class ConcreteFactoryB extends Factory2{
public IProductA getProductA2() {
return new ProductA2();
}
public IProductB getProductB2() {
return new ProductB2();
}
}
//测试类
public class Client {
public static void main(String[] args){
//厂商1负责生产产品A1、B1
Factory1 factory1= new ConcreteFactory1();
IProductA productA1 =factory1.getProductA1();
IProductB productB1 =factory1.getProductB1();
productA1.method();
productB1.method();
//厂商2负责生产产品A2、B2
Factory2 factory2= new ConcreteFactoryB();
IProductA productA2 =factory2.getProductA2();
IProductB productB2 =factory2.getProductB2();
productA2.method();
productB2.method();
}
}
运行结果：
| 厂商1 生产ProductA1 ... 厂商1 生产ProductB1 ... 厂商2 生产ProductA2 ... 厂商2 生产ProductB2 ... |
抽象工厂模式的优点与缺点：抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族，一般或多或少的都存在一定的关联，抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述，而不必专门引入一个新的类来进行管理。
产品族的扩展将是一件十分费力的事情，假如产品族中需要增加一个新的产品，则几乎所有的工厂类都需要进行修改。所以使用抽象工厂模式时，对产品等级结构的划分是非常重要的。
适用场景：当需要创建的对象是一系列相互关联或相互依赖的产品族时，便可以使用抽象工厂模式。说的更明白一点，就是一个继承体系中，如果存在着多个等级结构（即存在着多个抽象类），并且分属各个等级结构中的实现类之间存在着一定的关联或者约束，就可以使用抽象工厂模式。假如各个等级结构中的实现类之间不存在关联或约束，则使用多个独立的工厂来对产品进行创建，则更合适一点。
五、总结
简单工厂模式是由一个具体的类去创建其他类的实例，父类是相同的，父类是具体的。 工厂方法模式是有一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类，抽象工厂模式是工厂方法模式的升级版本。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，表现为一个接口或者抽象类，也就是说，工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。
无论是简单工厂模式，工厂方法模式，还是抽象工厂模式，他们都属于工厂模式，在形式和特点上也是极为相似的，他们的最终目的都是为了解耦。在使用时，我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式，因为他们之间的演变常常是令人琢磨不透的。经常你会发现，明明使用的工厂方法模式，当新需求来临，稍加修改，加入了一个新方法后，由于类中的产品构成了不同等级结构中的产品族，它就变成抽象工厂模式了；而对于抽象工厂模式，当减少一个方法使的提供的产品不再构成产品族之后，它就演变成了工厂方法模式。
所以，在使用工厂模式时，只需要关心降低耦合度的目的是否达到了就行。
468
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
