概述:
在软件系统中,经常面临着“某个对象”的创建工作,由于需求的变化,这个对象的具体实现经常面临着剧烈的变化,但是它却拥有比较稳定的接口。如何应对这种变化?提供一种封装机制来隔离出“这个易变对象”的变化,从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变?
意图:
定义一个用户创建对象的接口,让子类决定实例化哪一个类。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)由于考虑到系统的可扩展性,需要引入抽象层,在客户端代码中均使用抽象层进行定义,增加了系统的抽象性和理解难度。 工厂方法把简单工厂的内部逻辑判断移到客户端进行。
总结:以上纯属个人的理解,对于有些地方觉得还是理解不是很深,有不足之处和错误的地方希望大家帮我指出。谢谢