设计模式纵谈3-abstract factory

2、Abstract Factory 抽象工厂

new的问题
常规的对象创建方法:
//创建一个Road对象
Road raod = new Road();  【如果客户程序有很多地方调用此处，如果需要变化，改动的
地方很多，如果集中在一处（封装变化），则修改少】

new的问题:
--Singleton中：任何地方都可以new,无法确认唯一。
--实现依赖,不能应对“具体实例化类型”的变化。

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

工厂模式的缘起
--变化点在“对象创建”，因此就封装“对象创建”
--面向接口编程：依赖接口，而非依赖实现
[接口对内部表示变化，对外部表示不变化，封装变化，变化
封装就不变化，正好是接口，接口从不同的方面看，可看做变化
也可看做不变化]

--最简单的解决方法：  类库
class RoadFacotry{
   public static Road crateRoad(){
      return new Road();  //return new WaterRoad();
   }
}

创建一个Road对象 客户程序【调用程序的地方】
Road road = RoadFacotry.crateRoad();

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

Road road = roadFactory.createRoad();

Building building = roadFactory.createBuilding();

..........

class RoadFacotry{
   public static Road createRoad(){
    return new Road();
   }

   public static Building createBuilding(){
    return new Building();
   }
}

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

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

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

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

一组互相交互的对象，相互依赖的对象。

Build：对象整体和部分。

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

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

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

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

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

最令人敬佩的代码：写的非常简洁，还能把问题解决非常流畅。