述:

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

 

意图:

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

 

实质:

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

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

 

使用场景:

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

参与者:

  • 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)    收藏  举报