炎熱的季節又來到了，收拾櫥子整理衣服，發現冬天的大棉服還沒有收拾，到底是手洗呢？還是送到洗衣店呢？真的是愁啊？愁？
送到洗衣店不用自己動手，只要交上money就一切解決，是方便了，可是心疼那些錢啊，偷懶的同時心情也不是很好；不送到洗衣店，自己動手來解決，心情也不是很好，因為還得自己動手啊！面對那麼厚的衣服，不洗都感覺很累啊！突然間想到自己在家悠閒的日子了，因為又不用花錢，也不用自己動手啊！心情當然高興了！（一切老媽來搞定）。
這段小故事不就體現了兩個設計模式嗎？把衣服送到洗衣店，不用自己來面對那些棉服，洗衣液等等，很是方便。這就是設計模式中所謂的狀態模式；花錢了，心情很不舒服；花開的日子到了，出門踏青讓自己的心情得到了放鬆，某天因為一件小事而傷心了……心情的轉變不就是乙個狀態模式嗎？
來看看結構圖，理解一下：
外觀模式的結構圖：
（facade）：外觀類，知道哪些子系統類負責處理請求，將客戶的請求**給適當的子系統物件
（subsystem）：子系統類集合，實現子系統的功能，處理facade物件指派的任務。注意子類中沒有facade的任何資訊，即沒有對facade物件的引用。
狀態模式的結構圖：
（context）：維護乙個concretestate子類的例項，這個例項定義當前的狀態
首先從類圖關係的角度分析：外觀模式中，子系統類和外觀類之間是關聯關係；狀態模式中，子類與抽象狀態類之間是泛化關係，即所謂的繼承關係，如上文舉例當中，各種心情的變化，最終還是歸屬於狀態。
外觀模式是一種結構型模式；就上述例子而言，通過洗衣店把自己這個類和衣服這個類分離開來了，解決了類與類之間的依賴關係，外觀模式通過把他們的關係放在乙個facade中，降低了類類之間的耦合度。重要作用就是起到了解耦的作用。
狀態模式是一種行為型模式；將特定的狀態相關的行為放入乙個物件中，如上例，各種心情的狀態都可以存放在concretestate中，即定義新的子類可以很容易地增加新的狀態和轉換
外觀模式儲存了各個子系統物件，然後根據實際邏輯組合；狀態模式是允許乙個物件在其內部物件改變時改變它的行為，物件看起來似乎修改了它的類。
其實各種模式都得滿足於物件導向設計的最終目的，滿足於六大原則。
狀態模式二 外觀模式
外觀模式 為子系統定義一組統一的介面,這個高階的介面會讓子系統更容易被使用 比如汽車內部有許多子系統 引擎系統 傳動系統 懸吊系統 等 駕駛者只需要通過高階介面 方向盤 踏板 儀錶盤 就可以輕易操控汽車 優點 1,節省時間,減少系統耦合度 系統構建時間 2,易於分工開發,開發者只需要了解對方負責系統...
外觀模式 遊戲開發中的設計模式 外觀模式
外觀模式 facade 為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使子系統更加容易使用 依賴倒轉原則 迪公尺特法則思想 namespace 外觀模式 外觀類 class facade public void methodone public void methodtw...
介面卡模式與外觀模式
客戶新的需求，需要我們實現類似歐洲插座 電流介面卡 美國產筆記本插頭的東西，如下所示 使用介面卡模式充滿良好的oo設計原則 使用物件組合，以修改的介面包裝被適配者 同時被適配者的任何子類，都可以配著介面卡使用。需要注意 該模式是如何把客戶和介面繫結，而不是和實現繫結。上圖是物件介面卡，物件介面卡利用...