設計模式筆記 11 外觀模式(結構型)

2021-09-05 22:10:56 字數 1702 閱讀 9958

為子系統中的一組介面提供乙個一致的介面,façade模式定義了乙個高層介面,這個介面使得這一子系統更加容易使用。

先來看個小例子,假設我們需要開發乙個坦克模擬系統用於模擬坦克車在各種作戰環境中的行為,其中坦克系統由引擎、控制器、車輪、車身等各子系統構成。就會有下面這些類的產生

public class 

wheel

public class

engine

public class

controller

public class

bodywork

不同的場景中的要求都不一樣,可能會用到某些子系統,也可能不會用到,這些不同的場景就相當是外部介面,這些場景和子系統的關係如下圖:

上圖中的關係感覺很混亂,場景和子系統之間的耦合度很高,要降低這種耦合度,就要使和場景之間互動的不是這些子系統了,而是相對單一的乙個中間層,如下圖:

上圖的facade就將子系統隱藏了,不同的場景都是直接和facade互動。

上面圖1方案的問題在於元件的客戶和元件中各種複雜的子系統有了過多的耦合,隨著外部客戶程式和各子系統的演化,這種過多的耦合面臨很多變化的挑戰。如何簡化外部客戶程式和系統間的互動介面?如何將外部客戶程式的演化和內部子系統的變化之間的依賴相互解耦?這就要用到facade模式,先來看結構圖:

**實現,先定義一些子系統類

public class 

wheel

public void waction2()

}public class

engine

public void eaction2()

}public class

controller

public void caction2()

}public class

bodywork

public void baction2()

}

facade類,用來組合這些子系統

public class 

tankfacade

public void stop()

public void run()

public void shot()

}

客戶端呼叫

public class 

}

從客戶程式的角度來看, facade模式不僅簡化了整個元件系統的介面,同時對於元件內部與外部客戶程式來說,從某種程度上也達到了一種「解耦」的效果——內部子系統的任何變化不會影響到façade介面的變化。

façade設計模式更注重從架構的層次去看整個系統,而不是單個類的層次。façade很多時候更是一種架構設計模式。

注意區分façade模式、adapter模式、bridge模式與decorator模式。façade模式注重簡化介面,adapter模式注重轉換介面,bridge模式注重分離介面(抽象)與其實現,decorator模式注重穩定介面的前提下為物件擴充套件功能。

返回開篇(索引)

結構型設計模式 外觀模式

外觀模式為子系統中的一組介面提供了同意的介面,外觀模式定義了乙個高層介面,這個介面使得這一子系統更加容易使用。外觀模式中,客戶對各個具體的子系統是不了解的,所以對這些子系統進行了封裝,對外只提供了使用者所明白的單一而簡單的介面,使用者直接使用這個介面就可以完成操作,而不用去理睬具體的過程,而且子系統...

結構型設計模式 外觀模式

我們先來講乙個故事,比如我現在要組裝一台電腦。方案一 去電子市場買cpu,記憶體條,顯示卡,磁碟等所有用到的部件,然後再進行組裝。但是這個方案的問題在於,要對這些部件有所了解,選擇效能好的,考慮不同部件的相容性問題等。方案二 自己組裝太麻煩了,找個裝機公司吧,然後說自己的需求,之後就等著拿電腦就完事...

設計模式11 結構型模式之外觀模式

定義 外觀模式 fa ade pattern 為子系統中的一組介面提供乙個一致的介面,外觀模式定義了乙個高層介面,這個介面使得這一子系統更加容易使用。型別 結構型模式。適用性 當子系統非常複雜時,使得客戶呼叫非常麻煩,不便於使用。這個時候就可以使用外觀模式將這些子系統封裝起來,提供乙個統一而簡單介面...