原笔记:Abstract Factory

意图

Abstract Factory给一类class提供了一个统一接口。Client调用接口时会得到实际起作用的那一个class的实例。
而决定哪一个class起作用的是abstract factory。这样client便与class的具体实现解耦。

应用领域

-系统的实现不关心product是如何创建,组成,表示的;(系统只需要知道有这样一个product。)
-系统可以被一类product中的任意一个所配置;
-一类product的接口是相同的;(所有的类都是Abstract factory的子类)
-提供一个含有相同接口的class的库,你只想提供其接口,而不想提供它的具体实现。

结构

参与者

  • AbstractFactory
  • ConcreteFactory
  • AbstractProduct
  • ConcreteProduct
  • Client

作用过程

client调用AbstractFactory,而实际上,AbstractFactory会使用ConcreteFactory去实例化真正起作用的class
client通过AbstractProduct去处理ConcreteFactory返回的ConcreteProduct。通过继承和多态,这个设计是可以实现的。

优势与劣势

  • 实现了clientconcrete class的隔离。
    通常意义上,concrete class才是实际承担工作的class。如何使他们在一起工作?一个本能的想法就是,client直接调用concrete class
    但是当软件需求发生变化时,比如需要一个新的实现。我们将会被迫去修改所有client中对于上一个concrete class的调用。当使用Abstract Factory
    模式时,client不会关心实际的concrete class是什么。这样,当需求变化时,只需要修改abstract factory去返回新的concrete class
    而不需要改动client。而后者这种修改显然是更为便捷的。

  • 使得运行时改变生效的concrete class更为容易
    abstract factory模式下,改变其返回的concrete class是十分简单的。甚至可以在运行时完成转换。

  • 要求product具有一致性
    client通过AbstractProduct去操作实际的ConcreteProduct,显然,需要ConcreteProduct的接口一致。

  • 在添加新需求时缺乏灵活性
    ConcreteFactory需要与AbstractFactory的接口保持一致,但是如果在开发过程中出现了新的需求,将不可避免的要更改AbstractFactory
    然后,ConcreteFactory要保持一致的话也需要更改。在一个大型系统中,这个工作量是非常大的。

参考文献

  • [1] Gamma E, Helm R, Johnson R. Design Patterns: Elements of Reusable Object-Oriented Software [M]. Boston: Addison-Wesley, 1994.