Acstract Factory 抽象工厂（创建型模式）笔记

封装、多态、继承

new的问题

  常规的对象创建方法：

  Road road=new Road();

  new的问题：

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

  解决思路：

  封装变化点——哪里变化，封装哪里

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

  倾向于变化，变化速度

  稳定部分

工厂模式的缘起

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

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

  最简单的解决方法

  class RoadFactory

  {

    public static Road CreateRoad()

    {

    return new Road();

    //Road作为抽象类

    //return new WaterRoad();

    

    }

  }

-------------------------------------------------------------客户程序

  //创建一个Road对象

  Road road=RoadFactory.CreateRoad();

把常用的一段代码抽象成一个方法，把new 对象的方法抽象出来，以后改new 对象方法时就可以集中在一个地方改了。

封装 相互依赖的一系列对象

封装构造对象？ 感觉有些的地方创建对象的代码都一样

简单工厂的问题：

    不能应对“不同系列对象”的变化。比如有不同风格的游戏场景——对应不同风格的道路、房屋、地道......

解决之道：

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

稳定与变化 变化点

动机（Motivation）

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

    多系列

    连接不同类型的数据库（数据源）

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

 出现变化时，减少修改的地方，不用修改客户代码

意图（Intent）

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

结构（Structure）

   AbstractFactory:ConcreteFactory1

....

要点

   如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的静态工厂完全可以。
   “系列对象”指的是这些对象之间相互依赖、或作用的关系，例如游戏开发场景中的“道路”和“房屋”的依赖，“道路”与“地道”的依赖。
    Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

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

寻找变化点，隔离变化点；不同变化类型，应用不同模式。

不同模式组合来解决需求变化

.net 框架中不多，jave中挺多的