Abstract Factory

new的问题：
常规的对象创建方法：
Road road = new Road();

new的问题：
实现依赖，不能应付具体实例化类型的变化。

解决思路：
封装变化点-哪里变化，封装哪里
潜台词：如果没有变化，当然不需要额外的封装。

工厂模式的缘起：
变化点再对象创建，因此就封装对象创建
面向接口编程-依赖接口，而非依赖实现
最简单的解决方法：

--------------------------------------------------------------------------------------
class RoadFactory {                      类库
 public static Road CreateRoad() {
  return new Road();                    //return new WaterRoad();
 }
}

--------------------------------------------------------------------------------------

//创建一个Road对象                       客户程序
Road road = RoadFactory.createRoad();

创建一系列相互依赖的对象:
假设一个游戏开发场景：
我们需要构造道路房屋，地道，丛林等对象

class RoadFactory {
 public static Road CreateRoad() {
  return new Road();                        //return new WaterRoad()
 }

 CreateBuilding()
 CreateTunnel()
 CreateJungle()
}

Road road = RoadFactory.CreateRoad();

...       //客户相对稳定，但是类库有变化。

Building building = RoadFactory.CreateBuilding();

简单工厂的问题：
不能应付不同系列对象的变化。比如有不同风格的游戏场景-应对不同风格的道路，房屋，地道。。。

如何解决：
使用面向对象的技术来封装变化点

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

列对象的创建工作。
如何应对这种变化？如何绕过常规的对象创建方法，提供一种封装机制来避免客户程序和这种多系列具体

对象创建工作的紧耦合？

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

客户程序依赖AbstractFactory,AbstractProductA,AbstractProductB

Abstract Factory模式的几个要点：
1.如果没有应对多系列对象构建的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的

静态工厂完全可以。
2.系列对象指的是这些对象之间有相互依赖，或作用的关系，例如游戏开发场景中的道路与房屋的依赖，

道路与地道的依赖。
3.Abstract Factory模式主要在于应对新系列的需求变动。其缺点在于难以应对新对象的需求变动。
4.Abstract Factory模式经常和Factory Method模式共同组合来应对对象创建的需求变化。