《设计模式》之工厂方法

《设计模式》之工厂方法

前面介绍了简单工厂模式，这种模式的关键、核心在于工厂，他负责根据用户的需求返回相应的产品实例对象，这种设计模式的缺点就在于：

• 工厂的责任太大，当工厂不能够工作之后，整个设计就基本瘫痪
• 不遵守“开闭原则—对扩展开放，对修改关闭”，当需要增加一个新的产品类的时候，就需要修改工厂类的代码
• 当产品类达到一定的程序的时候，这个工厂的代码将非常庞大，不利用维护。

因此，就有了工厂方法模式

概念

工厂方法：一抽象产品类派生出多个具体产品类；一抽象工厂类派生出多个具体工厂类；每个具体工厂类只能创建一个具体产品类的实例。
即定义一个创建对象的接口（即抽象工厂类），让其子类（具体工厂类）决定实例化哪一个类（具体产品类）。“一对一”的关系。

UML图

• 工厂接口。工厂接口是工厂方法模式的核心，与调用者直接交互用来提供产品。在实际编程中，有时候也会使用一个抽象类来作为与调用者交互的接口，其本质上是一样的。
• 工厂实现。在编程中，工厂实现决定如何实例化产品，是实现扩展的途径，需要有多少种产品，就需要有多少个具体的工厂实现。
• 产品接口。产品接口的主要目的是定义产品的规范，所有的产品实现都必须遵循产品接口定义的规范。产品接口是调用者最为关心的，产品接口定义的优劣直接决定了调用者代码的稳定性。同样，产品接口也可以用抽象类来代替，但要注意最好不要违反里氏替换原则。
• 产品实现。实现产品接口的具体类，决定了产品在客户端中的具体行为。

实例

还是以昨天的车来举例。

有两个实例的产品：宝马、奥迪
有两个工厂：一个专门生产宝马车、一个专门生产奥迪车

源码

抽象产品

//抽象产品：车
public  interface Car {

}

具体产品类1

package com.wrh.factorymethod;
//具体产品类1：宝马
public class BMW implements Car{
    public BMW(){
        System.out.println("宝马车实例化");
    }
}

具体产品类2

package com.wrh.factorymethod;
//具体产品类2：奥迪
public class Audi implements Car{
    public Audi(){
        System.out.println("奥迪车实例化");
    }
}

抽象工厂类

package com.wrh.factorymethod;
//抽象工厂类
public interface AbstractFactory {
    public  Car factory();
}

具体工程类1

package com.wrh.factorymethod;
//具体工厂类：专门生产宝马车
public class ConcreteFactoryProduceBMW implements AbstractFactory{

    @Override
    public Car factory() {
        return new BMW();
    }

}

具体工厂类2

package com.wrh.factorymethod;
//具体工厂类2：专门生产奥迪车
public class ConcreteFactoryProduceAudi implements AbstractFactory{

    @Override
    public Car factory() {
        return new Audi();
    }

}

客户端

package com.wrh.factorymethod;

public class Test {

    public static void main(String[] args) {
        Car carAudi,carBMW;
        AbstractFactory factory1=new ConcreteFactoryProduceAudi();
        AbstractFactory factory2=new ConcreteFactoryProduceBMW();
        carAudi=factory1.factory();//第一个工厂返回奥迪车的实例
        carBMW=factory2.factory();//第二个工厂返回宝马的实例
    }

}

小结

工厂模式的优点

• 一对一的关系使工厂的功能单一化，不会造成简单工厂模式中的一旦工厂受损，整个奔溃的局面。
• 满足开闭原则，便于更好的扩展和维护

在以下情形，适合于工厂方法模式：

• 当不清楚具体产品类的个数的时候，即由单一的工厂不能生产所有的产品时（简单工厂模式就是由单一的工厂生产所有的产品）
• 当一个类希望由他的子类来指定它创建的对象的时候。即完成一个具体工厂指定一种具体产品的事情，使事情单一化。

实例应用

不管是简单工厂模式，工厂方法模式还是抽象工厂模式，他们具有类似的特性，所以他们的适用场景也是类似的。

• 首先，作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过new就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。
• 其次，工厂模式是一种典型的解耦模式，迪米特法则在工厂模式中表现的尤为明显。假如调用者自己组装产品需要增加依赖关系时，可以考虑使用工厂模式。将会大大降低对象之间的耦合度。
• 再次，由于工厂模式是依靠抽象架构的，它把实例化产品的任务交由实现类完成，扩展性比较好。也就是说，当需要系统有比较好的扩展性时，可以考虑工厂模式，不同的产品用不同的实现工厂来组装。

要说明工厂模式的优点，可能没有比组装汽车更合适的例子了。场景是这样的：汽车由发动机、轮、底盘组成，现在需要组装一辆车交给调用者。

假如不使用工厂模式，代码如下：

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();  
    }  
}  

使用工厂方法后，调用端的耦合度大大降低了。并且对于工厂来说，是可以扩展的，以后如果想组装其他的汽车，只需要再增加一个工厂类的实现就可以。无论是灵活性还是稳定性都得到了极大的提高。

参考资料：http://blog.csdn.net/zhengzhb/article/details/7348707