原笔记：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。通过继承和多态，这个设计是可以实现的。
优势与劣势
-
实现了
client与concrete 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.