工厂方法（Factory Method）创建型模式

概述:

在软件系统中，经常面临着“某个对象”的创建工作，由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化？提供一种封装机制来隔离出“这个易变对象”的变化，从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变？

意图:

定义一个用户创建对象的接口，让子类决定实例化哪一个类。Factory Method模式通过面向对象的手法，将所要创建的具体对象的创建工作延迟到子类，从而提供了一种扩展的策略，较好的解决了这种紧耦合的关系。

实质:

在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。在子类的内部创建对象通常比直接创建对象更灵活。随着需求的改变而改变，可以允许系统在不修改工厂角色的情况下引进新产品，同时工厂方法把简单工厂的内部逻辑判断移到客户端进行。

在客户程序中，有效地避免了具体产品对象和应用程序之间的耦合，但也增加了具体工厂对象和应用程序之间的耦合。

使用场景:

当一个类不知道它所必须创建的对象的类的时候。
当一个类希望由它的子类来指定它所创建的对象的时候。
当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。

参与者：

Product角色（抽象产品角色）: 定义了产品的共性，实现事物最抽象的定义。
Creator角色（抽闲工厂角色）: 定义了一个用于创建对象的接口，具体如何创建对象是由其子类（具体工厂）实现的。
ConcreteProduct（具体产品）: 实现了抽象产品所定义的接口。
ConcreteCreator（具体工厂）: 实现了创建对象的接口。

UML图：

　　抽象产品角色

public interface Product
    {

    }

　　具体产品

 public class ConcreteProductA : Product
    {

    }

    public class ConcreteProductB : Product
    {
    }

　　抽闲工厂角色

 public interface Creator
    {
        Product FactoryMethod();
    }

　　具体工厂

 public class ConcreteCreatorA : Creator
    {
        public Product FactoryMethod()
        {
            return new ConcreteProductA();
        }
    }

    public class ConcreteCreatorB : Creator
    {
        public Product FactoryMethod()
        {
            return new ConcreteProductB();
        }
    }

优点:

简单工厂模式随着产品类的增加需要修改静态工厂类，而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。工厂方法模式完全满足OCP，即它有非常良好的扩展性。

缺点:

1）在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。

2）由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度。工厂方法把简单工厂的内部逻辑判断移到客户端进行。

总结：以上纯属个人的理解，对于有些地方觉得还是理解不是很深，有不足之处和错误的地方希望大家帮我指出。谢谢

posted on 2012-12-28 18:25 雇佣兵333 阅读(745) 评论(0) 收藏举报