一、引言
每逢去吃午飯路上，幾個同事都要討論一番投資理財的事情，時間久之，小白的我才勉強了解到**與**的區別，**是自身直接與某只**交易，可以通過分紅或者低買高賣獲利（自身需要分析**多隻**的**，如圖示一）；而**是把錢交給**公司，有專業人員幫你分析**或債券等幫你理財（自身不需要直接關注**了，見圖示二）。
圖示一
圖示二在軟體開發中，客戶端系統經常會與複雜系統的內部子系統進行耦合，從而導致客戶端系統隨著子系統的改變而改變，為了讓客戶端系統與複雜系統的內部子系統解耦，從而有了外觀模式，也稱作「門面模式」，下面將介紹我們今天學習的外觀模式：
二、外觀模式的結構
外觀角色（facade）：被客戶client呼叫，知道各個子系統的功能，根據客戶的需要預訂幾種功能的組合
子系統角色（subsystem）：完成子系統功能，處理由facade物件分派的任務。對於子系統而言，facade和client角色是未知的
客戶角色（client）：通過呼叫facade完成相應的功能
三、外觀模式
定義：為子系統中的一組介面提供乙個一致的介面，此模式定義乙個高層介面，這個介面使得這一子系統更加容易使用
介紹了外觀模式的定義，下面我們通過兩個例子的對比分析幫助理解外觀模式，先看一下不使用外觀模式時的投資理財demo
//view code子系統 **一
class
subsystem1
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));
}public
void
sell()
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));}}
//子系統 **二
class
subsystem2
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));
}public
void
sell()
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));}}
//子系統 **三
class
subsystem3
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));
}public
void
sell()
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));}}
//客戶端呼叫
class
program
}
分析：從上面**可以看出，投資者需要了解每只**的**，每次需要在複雜的**中分析得出最優質的**，然後投資理財
下面看一下使用外觀模式的投資理財demo
//view code子系統 **一
class
subsystem1
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));
}public
void
sell()
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));}}
//子系統 **二
class
subsystem2
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));
}public
void
sell()
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));}}
//子系統 **三
class
subsystem3
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));
}public
void
sell()
中的方法
", this
.gettype().name, system.reflection.methodinfo.getcurrentmethod().name));}}
//外觀類 **公司
class
facadesystem
public
void
buy()
public
void
sell()
}//客戶端 投資**， **公司 負責理財
class
program
}
分析：從上面**可以看出，客戶端只依賴外觀類，投資者與**之間的依賴關係解耦了，如果**中某只****改變，此時投資者並不需要改變。
優點：
1.外觀模式對客戶遮蔽子系統元件，簡化了介面，減少了客戶處理的物件數量並使子系統的使用更加容易
2.外觀模式實現子系統和客戶之間的松耦合關係，而子系統內部之間可以是緊耦合的。松耦合使得子系統元件的變化不會影響到它的客戶
缺點：
在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的源**，違反了「開閉原則」
使用場景：
1.為乙個複雜系統提供簡單介面時。使得子系統更具可重用性，更容易 對子系統定製
2.引入facade將這個子系統與客戶以及其它子系統分離，可以提高子系統的獨立性和可移植性
3.當需要構建乙個層次結構的子系統時，使用facade定義每層的入口點。如果子系統之間是相互依賴的，可以讓它們僅通過facade進行通訊，簡化它們之間的依賴關係
物件導向程式設計思想 狀態模式
一 引言 上篇部落格中學習了中介者模式，我們留下了乙個問題，當出現多個玩家需要輸贏狀態條件判斷時，可不可以不去修改中介者類，因為如果每新增乙個條件判斷，就要修改中介者類，破壞了封裝，違背開閉原則。今天我們學習的內容就是要解決這種業務場景，狀態模式 二 狀態模式 定義 當乙個物件的內在狀態改變時允許改...
物件導向程式設計思想 命令模式
一 引言 起初餐館吃飯都是客人和廚師直接溝通，菜譜是一樣的，可是客人多了的時候，有的客人可能有急事不吃了要退單，還有的客人點很多菜需要記錄類別和次序等現象，這時服務員角色的出現解決了問題。那麼面對某些無法抵禦變化的 緊耦合 的場景如何做程式設計呢？命令模式設計便出現了，使得 行為請求者 與 行為實現...
物件導向程式設計思想
舉個最簡單點的例子來區分 有一天要請客吃飯，怎麼辦？有兩個方法 1 買菜，買調料，買肉，買酒水，然後下廚房動手炒菜 2 去飯店，點個 看出來區別了嗎？方法1是面向過程，方法2是物件導向。物件導向有什麼優勢？首先不需要知道各種菜式是怎麼做的，降低了耦合性。如果突然想換 了，對於方法1可能不太容易，因為...