创建模式：Abstract Factory 抽象工厂模式

前言

    创建型模式主要是解决new的问题

    常规的对象创建方法：

    //创建一个Road对象

    Road road = new Road();

   new的问题：

   ---实现依赖，不能应对“具体实例化类型”的变化

   解决思路：

   --封闭变化点——哪里变化，封闭哪里。

   --潜台词：如果没有变化，当然不需要额外的封装。

• 工厂模式的缘起

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

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

    3，最简单的解决方法

 class RoadFacotry{ public static Road CreateRoad(){ return new Road(); } } //创建一个Road对象 Road road = roadFactory.CreateRoad();

   4,创建一系列相互依赖的对象

     1> 假设一个游戏开发场景:

          我们需要构造“道路”、“房屋”、“地道”、“丛林”……等等对象

     代码：

   //客户端(相对稳定) Road road = roadFactory.CreateRoad(); //服务端(成为变化点) Building building = roadFactory.CreateBuilding(); class RoadFactory{ public static Road CreateRoad{return new Road();} public static Building CreateBuilding(){return new Building} public static Tunnel CreateTunnel(){return new Tunnel();} public static Jungle CreateJungle(){return new Junnel();} }

     2> 上述代码（简单工厂）问题：

          ——不能应对"不同系列对象"的变化，比如有不同风格的游戏场景—对应不同风格的道路、房屋、地道……

         如何解决：

         ——使用面向对象的技术来“封装”变化点

•  动机（Motivation）

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

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

• 意图

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

                                                                             ——《设计模式》GoF

 

• Abstract Factory

        1> 如果没有应对"多系列对象构建"的需求变化,则没有必要使用AbstractFactory模式,这时候使用简单的静态工厂完全可以

        2>"系列对象"指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。

        3>AbstractFactory模式主要在于应对 “新系列”的需求变动，其缺点在于难以应对“新对象”的需求变动。

        4>AbstractFactory模式经常和Factory Method模式共同组合来应对“对象创建”的需求变化。