1、系統的複雜度
需求:開發乙個坦克模擬系統用於模擬坦克車在各種作戰環境中的行為,其中坦克系統由引擎、控制器、車輪等各子系統構成.然後由對應的子系統呼叫.
常規的設計如下:
#region 坦克系統組成ok,這是最簡單的實現,完成了遊戲系統對坦克系統的呼叫,將上面的系統呼叫抽象成一張構成圖,如下://////引擎類
/// public
class
engine
public
void
engineactionb()
}//////
車輪
/// public
class
wheel
public
void
wheelactionb()
}//////
控制器
/// public
class
controller
public
void
controlleractionb()
} #endregion
//////
遊戲系統
/// public
class
gamesystem
}//////
車輪初始化類
/// public
class
wheelinit}}
可以發現,坦克系統的各個組成部分,柔和到了遊戲系統的各個型別中,這種設計一旦坦克的組成部分發生變化,所造成的維護成本是十分昂貴的!
2、問題
元件(坦克系統)的客戶端呼叫程式(系統系統)和元件中各種複雜的子系統之間產生了過多的耦合,隨著外部客戶程式和元件各子系統的演化,這種耦合產生的維護成本十分昂貴.
3、解決方案
必須抽象出一層介面,這層介面需要將坦克系統進行抽象,並告訴遊戲客戶端哪些功能,是它可以呼叫的,而不是讓系統系統自己去呼叫坦克系統的元件來實現相關的功能,將元件系統(坦克系統)和外部呼叫客戶程式(遊戲系統)的變化之間的依賴解耦.將這種變化成本交給這層介面來承擔.
#region 坦克系統組成客戶端呼叫**如下://////引擎類
/// internal
class
engine
public
void
engineactionb()
}//////
車輪
/// internal
class
wheel
public
void
wheelactionb()
}//////
控制器
/// internal
class
controller
public
void
controlleractionb()
}#endregion
public
class
tankfacade
//////
坦克的停止功能,完成引擎、控制器的停止
/// public
void
stop()
}
///通過tankfacade類,將坦克系統的元件整合到裡面,提供給遊戲系統它所需要的功能,很好的實現了客戶端呼叫系統依賴與坦克元件的問題,完成了解耦.解耦後的結構圖如下:///遊戲系統
/// public
class
gamesystem
//////
結束遊戲
/// public
void
stop()
}
4、要點
(1)、從客戶程式的角度來看,facade模式補不僅簡化了整個元件系統的介面,同時對於元件內部與外部客戶程式來說,達到了一種解耦的效果,內部子系統的變化不會影響到facade介面的變化.
(2)、facade模式更注重從架構的層次去看待整個系統,而不是單個類的層次,更多的時候是一種架構設計模式.
(3)、facede模式與apater模式、bridge模式、decorator模式的區別,facede模式注重簡化介面,apater注重轉換介面(將現有介面轉換成客戶需要的介面),bridge模式介面的分離(即系統按照兩個維度及以上的變化適合使用bridge模式),decorator模式注重穩定介面的情況下,為介面擴充套件功能.
設計模式 外觀模式（結構性） 模板模式（結構性）
外觀模式實現的是多各類協作共同完成一件事情，因此我們使用乙個函式來封裝這些操作，將這個函式放在乙個類中 模板模式實現的是乙個類的多個函式組合完成一件事情，雖然類的每個函式可能有不同的實現方式，但是流程是一樣的。因此使用繼承方式，在類中新建乙個函式依次呼叫其他的成員函式。模板模式中將乙個大函式拆分為小...
外觀模式（Facade）
外觀模式的定義是，為子系統中的一組介面提供乙個一致的inte ce介面介面。外觀模式是個很簡單，但很重要的模式，它主要思想是將表現層和邏輯層隔離，封裝底層的複雜處理，只為使用者提供簡單的介面，這樣的例子隨處可見。外觀模式也叫門面模式，它很多時候更是一種系統架構的設計，在我所做的專案中，就實現了門面模...
Facade外觀模式
facade外觀模式，是一種結構型模式，它主要解決的問題是 元件的客戶和元件中各種複雜的子系統有了過多的耦合，隨著外部客戶程式和各子系統的演化，這種過多的耦合面臨很多變化的挑戰。facade設計模式更注重從架構的層次去看整個系統，而不是單個類的層次。facade外觀模式，是一種結構型模式，它主要解決...