建立型模式：抽像工廠模式（Abstract Factory）

                                                建立型模式：抽像工廠模式（Abstract Factory）
１、new的問題
常規的對象建立方法：
  // 建立一個Road對象
  Road road = new Road();
new的問題：
－實現依賴，不能應對「具體實例化類型」的變化。
解決思路：
－封裝變化點——哪裏變化，封裝哪裏
  －潛臺詞：若是沒有變化，固然不須要額化的封裝！
 
２、工廠模式的緣起
  變化點在「對象建立」，所以就封裝「對象建立」
  面向接口編程——依賴接口，而非依賴實現
  最簡單的解決方法：
  class RoadFactory{       // 類庫
    public static Road CreateRoad(){
      return new Road();
      // Road是個抽象類，返回一個特定的工廠
      // return new WaterRoad();
    }
  }
 
  // 客戶程序：建立一個Road對象
  Road road = roadFactory.CreateRoad();

３、假設一個遊戲開發場景：
  咱們須要構造「道路」、「房屋」，「地道」、「叢林」等對象，咱們須要創建一系列對象，這些對象相互依賴 
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 Jungle();  // 建立叢林
  }
}
  純靜態的方法很差，上述代碼若是需求改變，它多是變化點
 
４、簡單工廠的問題
  不能應對「不一樣系列對象」的變化。好比有不一樣風格的，遊戲場景——對應不一樣風格的道路、房屋、地道、叢林等
  如何應對這種變化，如何解決： 使用面嚮對象的技術來「封裝」變化點。
５、動機(Motivation)
    在軟件系統中，常常面臨着「一系列相互依賴的對象」的建立工做；同時，因爲需求的變化，每每存在更多系列對象的建立工做。
    如何應對這種變化？如何繞過常規的對象建立方法（new），提供一種「封裝機制」來避名免客戶程序和這種「多系列具體對象建立工做」的緊耦合？
６、意圖(Intent)
    提供一個接口，讓該接口負責建立一系列「相關或者相互依賴的對象」，無需指定它們具體的類。
７、具體實現
//道路
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 FacilitiesFactory
{
  public abstract Road CreateRoad();
  public abstract Building CreateBuilding();
  public abstract Tunnel CreateTunnel();
  public abstract Jungle CreateJungle();
}

public class ModernFacilitiesFactory : FacilitiesFactory
{
  public override Road CreateRoad()
  {
    return new ModernRoad();
  }
  public override Building CreateBuilding()
  {
    return new ModernBuilding();
  }
  public override Tunnel CreateTunnel()
  {
    return new ModernTunnel();
  }
  public override Jungle CreateJungle()
  {
    return new ModernJungle();
  }
}

客戶程序：整個診賴於抽象工廠，沒有依賴具體的實現，咱們的目的是須要GameManager類穩定下來，不須要變更。
class GameManager
{
  private FacilitiesFactory facilitiesFactory;
  private Road road;
  private Building building;
  private Tunnel tunnel;
  private Jungle jungle;
  public GameManager(FacilitiesFactory facilitiesFactory)
  {
    this.facilitiesFactory = facilitiesFactory;
  }
 
  public void BuildGameGameFacilities()
  {
    road = facilitiesFactory.CreateRoad();
    building = facilitiesFactory.CreateBuilding();
    tunnel = facilitiesFactory.CreateTunnel();
    jungle = facilitiesFactory.CreateJungle();
    //若是設施變化劇烈，這裏抽象工廠就是誤用，變化劇烈的應該是這些設施的風格
  }
 
  public void Run()
  {
    road.A();
    building.B(road);
    tungle.C();
    jungle.D();
  }
}

class App
{
  public static void Main()
  {
    //只需改這裏就行，須要什麼風格就new什麼風格，這裏運行現代風格new ModernFacilitiesFactory()
    FacilitiesFactory facilitiesFactory = new ModernFacilitiesFactory()
    //能夠從web.config文件中設置相關，利用.net的反射獲得特定風格的工廠
    GameManger gm = new GameManager(facilitiesFactory);
    gm.BuildGameGameFacilities();
    gm.Run();
  }
}

８、Abstract Factory模式的幾個要點
  １）若是沒有應對「多系列對象構建」的需求變化，則沒有必要使用抽像工廠模式，這時候使用簡單的靜態工廠徹底能夠。
  ２）「系列對象」指的是這些對象之間有相互依賴、或做用的關係，例如遊戲開發場景中的「道路」的依賴，「道路」與「地道」的依賴。
  ３）抽像工廠模式主要在於應對「新系列」的需求變更。其缺點在於難以應對「新對象」的需求變更。
  ４）抽像工廠模式常常和工廠方法模式共同組合來應對「對象建立」的需求變化。