抽象工厂(创建型模式)
new的问题:
实现依赖,不能应对“具体实例化类型”的变化。
解决思路:
1.封装变化点 ---- 那里变化,封装那里。
2.潜台词:如果没有变化,当然不需要额外的封装 !
工厂模式的源起:
变化点在“对象创建”,因此就封装“对象创建”
面向接口编程 -- 依赖接口,而非依赖实现。
Road road = RoadFactory.CreateRoad();
class RoadFactory
{
public static Road CreateRoad()
{
return new Road();
}
}
如何解决:
使用面向对象的技术来“封装”变化点。
动机:
在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作;
同时,由于需求的变化,往往存在更多系列对象的创建工作。
如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种
“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的
紧耦合。
提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,
无需指定它们的具体的类。--GOF
类与类之间的关联时依靠于接口或抽象类而不是依赖于具体的类。
Abstract Factory 要点:
1.如果没有应对“多系统对象构建”的需求变化,则没有必要使用Abstract Factory
模式,这时候使用简单的静态工厂完全可以。(对象结构稳定)
2."系列对象"值得是这些对象之间有相互依赖,或作用的关系,例如游戏开发
场景中的"道路"与"房屋"的依赖,"道路"与"地道"的依赖.
3.Abstract Factory模式主要在于应对"新系列"的需求变动.其缺点在于难以应对
"新对象"的需求变动.
4.Abstract Factory模式经常和Factory Method模式共同组合来应对"对象创建'
的需求变化.