设计模式---abstract Factory --创建型

面向对象解决的是封装变法点
new的问题
常规的对象创建方法：
// 创建一个Road 对象
Road road=new Road();
new的问题：
– 实现依赖，不能应对“具体实例化类型”的变化。
解决思路：
– 封装变化点—— 哪里变化，封装哪里
– 潜台词：如果没有变化，当然不需要额外的封装！

工厂模式的缘起
? 变化点在“对象创建”，因此就封装“对象创建”
? 面向接口编程——依赖接口，而非依赖实现
? 最简单的解决方法：
class RoadFactory{
public static Road CreateRoad()
{
return new Road();
}
}
// 创建一个Road 对象
Road road=
roadFactory.CreateRoad();

假设一个游戏开发场景：
我们需要构造“道路”、
“房屋”、“地道”、“丛
林”……等等对象

创建一系列相互依赖的对象
-----相对变化

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 Jungle();
}


-------------------这块代码相对稳定
Road road=
roadFactory.CreateRoad(
);
…
Building building=
roadFactory.CreateBuilding();
…

 

简单工厂的问题
简单工厂的问题：
– 不能应对“不同系列对象”的变化。比如有不同风格的游
戏场景——对应不同风格的道路、房屋、地道……
如何解决：
– 使用面向对象的技术来“封装”变化点

动机（Motivation）
在软件系统中，经常面临着“一系列相互依赖的对象”的创建
工作；同时，由于需求的变化，往往存在更多系列对象的
创建工作。
如何应对这种变化？如何绕过常规的对象创建方法(new)，
提供一种“封装机制”来避免客户程序和这种“多系列具体对
象创建工作”的紧耦合？

意图（Intent）
提供一个接口，让该接口负责创建一系列“相关或者
相互依赖的对象”，无需指定它们具体的类。
——《设计模式》GoF

结构（Structure）

//道路
public abstract class Road
...{

}
//房屋
public abstract class Building
...{

}
//地道
public abstract class Tunnel
...{

}
//丛林
public abstract class Jungle
...{

}

//道路
public  class ModernRoad:Road
...{
.....
}
//
public  class ModernBuilding:Building
...{

}
public  class ModernTunnel:Tunnel
...{

}
public  class ModernJungle:Jungle
...{
   ....
}




 

  abstract class FacilitingFactory...{
public abstract  Road CreateRoad();

public abstract Building
CreateBuilding();

public abstract Tunnel
CreateTunnel();

public abstract l Jungle
CreateJungle();
}

/**//////////////////////

class ModernFacilitingFactory:FacilitingFactory...{
public overide Road CreateRoad()
...{
return new ModernRoad();
}
public overide Building
CreateBuilding()
...{
return new ModernBuilding();
}
public overide Tunnel
CreateTunnel()
...{
return new ModernTunnel();
}
public override Jungle
CreateJungle()
...{
return new ModernJungle();
}


//客户程序
class GameManager
...{  
   Road road;
   Building building;
   Jungle jungle ;
   Tunnel tunnel ;
   FacilitiesFactory facilitiesFactory;

  public  GameManger(FacilitiesFactory facilitiesFactory)
...{
  this.facilitiesFactory facilitiesfactory;
}
  public void BuildGameFacilities()
...{
     road=facilitiesFactory.CreateRoad();
     building=facilitiesFactory.CreateBuilding();
     tunnel=facilitiesFactory.createTunnel();
     jungle=facilitiesFactory.createJungle();
}
  pulic void play()
...{
   ......
    ......
   
}

}

class App
...{
   public static void Main()
...{

    GameManger g= GameManger(xxxxx);
    g.BuildGameFacilities();
   g.play();
}
   
}

 

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