前言：讓介面變得簡單。
例子說明：
req1vander之前剛完成了上個設計，賺了很多錢，現在它入手了一整套小公尺裝備，有小公尺音響、小公尺空調、小公尺空氣淨化器、小公尺爆公尺花機、小公尺投影儀、小公尺投影幕布，它想在家裡開影院，製造乙個良好的氛圍來好好享受這個週末。有以下這些家電：
分析：先來看看類圖，vander發現買了一堆裝置，花了一大堆時間終於把這些裝置連線起來了，接下來要開啟這些裝置，想看一部電影需要完成：
1、開啟影院燈，調節成dim
2、開啟空氣淨化器
3、放下螢幕
4、開啟投影
5、將投影的輸入切換到***
6、設定投影成寬屏模式
7、開啟功放
8、功放的輸入為***
9、調節功放音量
10、開啟***
涉及到如此多的類，看完電影之後還要乙個個關掉，這才頭疼，vander心想：想過個心情愉悅的週末就這麼難嗎？將所有的步驟寫在一起，按照一定的順序，讓乙個總控來幫我完成這些事情。然後vander定義了乙個家庭影院外觀（hometheate***cade）。
分析：外觀模式允許我們讓客戶和子系統之間避免緊耦合。
外觀模式：提供乙個統一的介面，用來訪問子系統中的一群介面。外觀定義了乙個高層介面，讓子系統更容易使用。
這個模式可以通過實現乙個提供更合理的介面的外觀類，可以將乙個複雜的子系統變得容易使用。外觀模式不只是簡化了介面，也將客戶從元件的子系統中解耦。
外觀模式和介面卡模式比較： 1
、外觀和介面卡都可以包裝許多類 2
、外觀的意圖是簡化介面 3
、介面卡的意圖是將介面轉成所需的介面
下面是模式的一般類圖：
介面卡模式很好地運用了
oo的設計原則，使用物件組合，以修改的介面包裝被適配者。
影院物件：
public class hometheate***cade
public void watchmoive(string moive)
public void endmoive()
public void watchtv()
public void closetv()
}
public class amplifier
public void off()
public void setvolume(int volume)
public void set***player(***player ***player)
public void settelevision(television television)
public void play() else if(this.television != null ) else
system.out.println("amplifier is" + this.volume); }
}
其餘的類都比較類似，這裡不一一枚舉了，這裡只是為了說明
hometheate***cade
提供了乙個簡化的介面，讓使用者呼叫起來非常方便。
有了外觀模式最大的好處是減少了客戶跟子系統之間的緊密耦合，外觀模式幫我們很好地實現了乙個原則——最小知識原則（law of demeter[墨忒耳法則]）。
最小知識原則——只和你的密友談話。
意思是在設計乙個系統的時候不管是任何物件都要注意它所互動的類有哪些，注意它和這些類是如何互動的。這個原則希望我們在設計中不要讓太多的類耦合在一起，免得修改系統中的一部分會影響到其他部分。如果許多類之間相互依賴，那麼這個系統就是乙個易碎的系統。
遵循這個原則，我們物件設計中，該物件方法裡只應該呼叫屬於以下範圍的方法： 1
、該物件本身 2
、被當做方法的引數而傳遞進來的物件 3
、此方法所建立或例項化的任何物件 4
、物件的任何元件
前三條告訴我們，如果某物件是呼叫其他的方法的返回結果，不要呼叫該物件的方法。
第4條告訴我們裝配進來的可以呼叫。
exp：
public float gettemp()
public float gettemp()
舉例說明以上四種範圍的方法能夠被呼叫的情景：
為了加深對這個原則的理解，下面再看兩段**：
house1：
public class house1
}
明顯違反了最少知識原則，因為它呼叫的方法屬於第一次呼叫返回的物件。
house2：
public class house2
private float gettemphelper(thermometer thermometer)
}
缺點：最小知識原則雖然減少了物件之間的依賴，也減少了軟體的維護成本，但是採用這個原則也會導致更多的「包裝」類，以處理和其他元件的溝通，這可能會導致複雜度和開發時間的增加，並降低執行時的效能。
最後又到了喜聞樂見的總結部分，我們又來總結我們現在現有的設計模式**。
抽象、封裝、多型、繼承
設計原則一：封裝變化
設計原則二：針對介面程式設計，不針對實現程式設計。
設計原則三：多用組合，少用繼承。
設計原則四：為互動物件之間的松耦合設計而努力
設計原則五：對擴充套件開放，對修改關閉
設計原則六：依賴抽象，不要依賴於具體的類
設計原則七：只和你的密友談話
外觀模式：提供了乙個統一的介面，用來訪問子系統中的一群介面。外觀定義了乙個高層介面，讓子系統更容易使用。
設計模式 外觀模式
外觀模式，我的理解就是將複雜的類進行重新封裝，將簡單的介面呈現出來，降低呼叫端和實際類的耦合性。拿 大話設計模式 上邊關於 和 的例子來說。對於不入門的股民來說，交易有些過於龐大，需要學習的東西很多，如果沒整明白就進行投資，很容易賠錢的。很多剛入 的股民都賠的很慘。而買 有提出了乙個新的觀念，我們買...
設計模式 外觀模式
何為外觀模式？外觀模式 為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得一子系統更加容易使用。它是一種結構型模式，它主要解決的問題是 元件的客戶和元件中各種複雜的子系統有了過多的耦合，隨著外部客戶程式和 各子系統的演化，這種過多的耦合面臨很多變化的挑戰。uml類圖 乙個...
設計模式 外觀模式
外觀模式說白了就是為一組介面提供乙個一致的介面。例如 定義三個類a b c，每個類各定義乙個方法。class a pubic void showa cout a showa pubic void showb cout b showb pubic void showc cout c showc 定義乙...