设计模式 -- Abstract Factory 抽象工厂

1、常规的对象创建方法

//创建一个Road对象

Road road=new Road();

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

解决思想：

封装变化点--哪里变化，封装哪里（如果没有变化，当然不需要额外的封装）。

2、工厂模式的缘起

变化点在“对象创建”，因此就封装“对象创建”

面向接口编程--依赖接口，而非依赖实现

解决方法：      类库

class RoadFactory{

public static Road CreateRoad()

{

return newRoad();

}

}

---

//创建一个Road对象   客户程序

Road road=roadFactory.CreateRoad();

3、游戏开发场景。我们需要构建“道路”，房屋，地道，丛林。。。等等对象。

创建一系列对象（相互依赖的）

Road road=roadFactory.CreateRoad()

.............[相对稳定]

class RoadFactory{

　　public static Road CreatRoad

　　{

　　　　return new Road();  //如果需求变化了，这里就成了变化点了

　　}

　　public static Building CreatBuilding　　{

　　　　return new Building();

　　}

　　public static Tunnel CreatTunnel　

　{

　　　　return new Tunnel();

　　}

　　public static Jumgle CreatJumgle

　　{

　　　　return new Jumgle();

　　}

}

4、简单工厂的问题

不能应对“不同系列对象”的变化，

静态方法工厂这里成了变化点。比如有不同风格的游戏场景--对应不同的道路、房屋、地道。

解决方法：抽象封装、

5、动机

在软件系统中，惊颤面临着“一系列相互依赖的对象”的创建工作；同事，由于需求的变化，往往在更多系类对象的创建工作。

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

6、意图

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

----(设计模式)GOF

7、结构（Structre）

 

左边是类库，右边是客户程序。

A1和B1是相互依赖的，A2和B2是相互依赖的。