Abstract Factory 抽象工廠模式(建立型模式):

new的問題:實現依賴,不能應變應對“具體例項化型別”的變化。

解決思路:--封裝變化點:哪裡變化,封裝哪裡           -

-潛臺詞:如果沒有變化,當然不需要額外的封裝

工廠模式的緣起

變化點在“物件建立”,因此就封裝“物件建立”

面向介面的程式設計——依賴介面,而非依賴實現

簡單工廠的問題     --不能應對“不同系列物件”的變化。比如有不同風格的遊戲場景——對應不同風格的道路,房屋,地道。。。。

——如何解決:使用面嚮物件的技術來“封裝”變化點

抽象工廠模式

動機(Motivation):在軟體系統中,經常面臨著“一系列相互依賴的物件”的建立工作;同時,由於需求的變化,往往存在更多系列物件的建立工作。如何應對這種變化?如何繞過常規的物件建立方法(new),提供一種“封裝機制”來避免客戶程式和這種“多系列具體物件建立工作”的緊耦合?

意圖(Intent):提供一個介面,讓該介面負責建立一系列“相關或者相互依賴的物件”,無需指定他們的具體類《設計模式》GOF

實現程式碼

public abstract class Road//道路

{ }

public abstract class Building//房屋

{ }

public abstract class Tunnel//地道

{ }

public abstract class Jungle//叢林

{ }

abstract class FacilitiesFactory

{   

public abstract Road CreateRode();   

public abstract Building CreateBuilding();   

public abstract Tunnel CreateTunnel();   

public abstract Jungle CreateJungle();

}

//客戶程式

class GameManager

{   

FacilitiesFactory  facilitiesFactory;    

Road road;   

Building building;   

Tunnel tunnel;   

Jungle jungle;   

public GameManager(FacilitiesFactory  facilitiesFactory)

 {        

this.facilitiesFactory=facilitiesFactory;  

}    

public void BuildGameFacilities()

 {     

    road=facilitiesFactory.CreateRoad();     

   building=facilitiesFactory.CreateBuilding();   

   tunnel=facilitiesFactory.CreateTunnel();     

    jungle=facilitiesFactory.CreateJungle();  

}    

  public void Run()  

  {      

      road.Aaa();      

     building.Bbb();  

  }

}

//現代的風格

public class ModernRoad:Road//道路

{ }

public  class ModernBuilding:Building//房屋

{ }

public  class ModernTunnel:Tunnel//地道

{ }

public  class ModernJungle:Jungle//叢林

{ }

//具體的實現

public class ModernFacilitiesFactory:FacilitiesFactory

{     

public override Road CreateRode()  

{     

return new ModernRoad();  

}     

public override Building CreateBuilding()  

{    

  return new ModernBuilding();  

}

public override Tunnel CreateTunnel()  

{     

return new ModernTunnel();  

}

   public override Jungle CreateJungle()  

{     

return new ModernJungle();

  }

}

class APP

{   

GameManager g=new (new ModernFacilitiesFactory());   

g.BuildGameFacilities();   

g.Run();

}

Abstract Factory模式的幾個要點:

——如果沒有應對“多系列物件構建”的需求變化,則沒有必要使用Abstract Factory模式,這時候使用簡單的靜態工       廠完全可以。

——“系列物件”指的是這些物件之間有相互依賴,或作用的關係,例如遊戲開發場景中的“道路”與“房屋”的依賴,“道路”與“地道”的依賴

——Abstract Factory模式主要在於應對“新系列”的需求變動。其缺點在於難以應對“新物件”的需求變動 ——Abstract Factory模式經常和Factor Method模式共同組合來應對“物件建立”的需求變化