抽象工厂模式

理论部分

-动机

在软件系统中，经常面临着"一系列相互依赖的对象”的创建工作。"同时，由于需求的变化，往往存在更多系列对象的创建工作。

如何应对这种变化?如何绕过常规的对象创建方法(new)，提供一种“封装机制"来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?

-模式定义

提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。

-结构(类图)

-要点总结

如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂完全可以。

“系列对象"指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。

Abstract Factory模式主要在于应对“新系列"的需求变动。其缺点在于难以应对“新对象”的需求变动。

设计思路及代码

设计思路：

①假设同系列的A1与B1是扫把和簸箕，需要一起使用才能扫地，同系列的A2与B2是拖把和拖把桶,需要一起使用才能拖地，显然不能用A1与B2来配套使用。

②利用抽象工厂把不同的工厂汇集一起，把系列1的产品给工厂1，系列2的产品给工厂2，系列1有产品A1和B1，系列2有产品A2和B2，使用时被抽象为产品1，不会被混用为产品2。

③情景假设：抽象工厂模式中，如果需要新增加一个系列的产品，比如3系列：A3:毛巾/B3：脸盘，只需增加一族新的具体产品类（抽象和具体）并提供一个对应的工厂类即可。但是,如果要在已有的产品族1里增加另一个产品，比如我想扫地，除了需要扫把和簸箕外，还想用吸尘器C1。

Q：这时候该怎么办呢？是不是要去修改ConcreteFactory1类呢？
A：显然这个需求并不适合用抽象工厂模式来满足，若修改ConcreteFactory1类,代表违反了开放封闭原则:对扩展开放,对更改封闭。这也恰恰是抽象工厂的缺点：难以应对“新对象”的需求变动。

代码如下：

执行结果如下：