設計模式之外觀模式

在工作的時候我們實現乙個功能通常需要多個方法合作完成，如果別人需要呼叫我們的功能就需要知道多個方法的關係或者順序，如果我們提供乙個整合了這些方法的介面，別人只需要呼叫介面就可以了，不需要關心介面是怎麼實現的。

提供乙個統一的介面，用來訪問子系統中的一群介面。外觀定義了乙個高層介面，讓子系統更容易使用。允許我們讓客戶和子系統之間避免緊耦合，且遵循了「最少知識」設計原則。

舉兩個簡單的例子。我們生病的時候去藥店拿藥只需要跟醫生說明症狀，醫生會對症下藥，如果沒有醫生，我們就需要自己懂得什麼病吃什麼藥，這裡的醫生就是「高層介面」，什麼病吃什麼藥就是「子系統」；我們去婚介所找老婆的時候也是只需要跟婚介所說明要求，婚介所就會給我們提供滿足要求的人選，這裡婚介所就是「高層介面」，匹配滿足要求的人選就是「子系統」。這裡的子系統可以是乙個，也可以是多個，但客戶只與高層接**互。

有乙個大象機械人（高層介面），我們只需要告訴它「把大象放進冰箱」，它就會把大象放進冰箱，至於怎麼放進去的我們不用關係。在這裡我們暫時設計三步（子系統）：1.開啟冰箱門 2：把大象放進去 3：關閉冰箱門。

子系統（放大象步驟）：

class door 
public void closethefridgedoor()
}class elephant 
}

高層介面（大象機械人）：

class elephantrobot 
public void puttheelephantinthefridge()
}

測試程式及輸出結果：

測試程式：
public static void main(string args) 
輸出結果：
把大象放進冰箱：
第一步：開冰箱門...
第二步：把大象放進去...
第三步：關冰箱門...

可以看到客戶端只需要呼叫高層介面（大象機械人）即可，並不需要關心子系統的順序及關係，客戶端與子系統是低耦合的。但我又想讓大象機械人把駱駝放進冰箱或者把大象放進洗衣機又或者讓鴕鳥給我做蛋炒飯呢？很明顯，大象機械人滿足不了需求，在此類上修改則違反了開閉原則。本著針對介面程式設計而不是對實現程式設計的設計原則，這裡的大象機械人（高層介面）應該抽象出來。

子系統新增了駱駝類：

class camel 
}

抽象外觀類（智慧型機械人）：

abstract class intelligentrobot

外觀類：

//大象機械人
class elephantrobot extends intelligentrobot
public void putitinthefridge()
}//駱駝機械人
class camelrobot extends intelligentrobot 
@override
public void putitinthefridge() 
}

測試程式及輸出結果：

//測試程式
public static void main(string args) 
//輸出結果
把大象放進冰箱：
第一步：開冰箱門...
第二步：把大象放進去...
第三步：關冰箱門...
把駱駝放進冰箱：
第一步：開冰箱門...
第二步：把駱駝放進去...
第三步：關冰箱門...

其實抽象外觀類和具體外觀類這裡有點像策略模式，但策略模式傾向於對演算法的互相替換，外觀模式再怎麼抽象也是對一組子系統的操作，不能脫離這組子系統。

以下從其他地方看來的，侵刪！

降低客戶端與子系統的耦合度，客戶端只需要與高層接**互；

可以通過控制高層介面控制客戶端的許可權。

抽象外觀類不太好設計（具體場景具體分析），容易違反開閉原則。

設計模式之外觀模式

設計模式之外觀模式

設計模式之外觀模式

設計模式之外觀模式

相關推薦