1.外觀模式簡(jiǎn)介
外觀模式(Facade)在開發(fā)過程中的運(yùn)用頻率非常高，尤其是在現(xiàn)階段各種第三方SDK充斥在我們的周邊奏寨，而這些SDK很大概率會(huì)使用外觀模式榛搔。通過一個(gè)外觀類使得整個(gè)系統(tǒng)的接口只有一個(gè)統(tǒng)一的高層接口抖部，這樣能夠降低用戶的使用成本疲眷，也對(duì)用戶屏蔽了很多實(shí)現(xiàn)細(xì)節(jié)。當(dāng)然您朽，在我們的開發(fā)過程中狂丝，外觀模式也是我們封裝API的常用手段换淆，例如網(wǎng)絡(luò)模塊、ImageLoader模塊等几颜。
2.外觀模式定義
外觀模式又叫門面模式倍试。外觀模式為子系統(tǒng)中一組不同的接口提供統(tǒng)一的接口。外觀模式定義了上層接口蛋哭，通過降低復(fù)雜度和隱藏子系統(tǒng)間的通信及依存關(guān)系县习，讓子系統(tǒng)更易于使用。
3.外觀模式的使用場(chǎng)景
3.1 ?為一個(gè)復(fù)雜子系統(tǒng)提供一個(gè)簡(jiǎn)單接口谆趾。子系統(tǒng)往往因?yàn)椴粩嘌莼兊迷絹碓綇?fù)雜躁愿，甚至可能被替換。大多數(shù)模式使用時(shí)都會(huì)產(chǎn)生更多沪蓬、更小的類彤钟，在這使子系統(tǒng)更具可重用性的同時(shí)也更容易對(duì)子系統(tǒng)進(jìn)行定制、修改跷叉，這種易變性使得隱藏子系統(tǒng)的具體實(shí)現(xiàn)變得尤為重要逸雹。Facade可以提供一個(gè)簡(jiǎn)單統(tǒng)一的接口，對(duì)外隱藏子系統(tǒng)的具體實(shí)現(xiàn)云挟、隔離變化梆砸。
3.2 當(dāng)你需要構(gòu)建一個(gè)層次結(jié)構(gòu)的子系統(tǒng)時(shí)，使用Facade模式定義了子系統(tǒng)中每層的入口點(diǎn)园欣。如果子系統(tǒng)之間是相互依賴的帖世，你可以讓它們僅通過Facade接口進(jìn)行通信，從而簡(jiǎn)化了它們之間的依賴關(guān)系沸枯。
4.外觀模式的UML 圖
5.角色劃分
外觀角色(Facade)：是模式的核心狮暑，他被客戶client角色調(diào)用，知道各個(gè)子系統(tǒng)的功能辉饱。同時(shí)根據(jù)客戶角色已有的需求預(yù)訂了幾種功能組合
子系統(tǒng)角色（Subsystem classes)：實(shí)現(xiàn)子系統(tǒng)的功能，并處理由Facade對(duì)象指派的任務(wù)拣展。對(duì)子系統(tǒng)而言彭沼，facade和client角色是未知的，沒有Facade的任何相關(guān)信息备埃；即沒有指向Facade的實(shí)例姓惑。
6.Demo 實(shí)踐
? 業(yè)務(wù)場(chǎng)景如下：
? ? ? ? ? 有一位乘客需要乘坐出租車，出租車司機(jī)為駕駛出租車的一組復(fù)雜接口提供了一個(gè)簡(jiǎn)化了的接口按脚。如圖：
?通過此圖可以看出整個(gè)出租車服務(wù)作為一個(gè)封閉系統(tǒng)于毙，包括一名出租車司機(jī)（外觀角色）、一輛車（子系統(tǒng)角色）辅搬、一個(gè)計(jì)價(jià)器（子系統(tǒng)角色）唯沮。同系統(tǒng)交互的唯一途徑是通過CabDriver中定義的接口driveToLocation:x脖旱。一旦乘客（客戶client角色）向出租車司機(jī)發(fā)出driveToLocation:x消息。CabDriver就會(huì)收到消息介蛉。司機(jī)需要操作兩個(gè)子系統(tǒng)---Taximeter（計(jì)價(jià)器）和Car萌庆。CabDriver先啟動(dòng)（start）Taximeter,讓他開始計(jì)價(jià)，然后司機(jī)對(duì)汽車會(huì)松剎車（releaseBrakes）币旧、換擋（changeGears）践险、踩油門（pressAccelerator）,把車開走。直到到達(dá)了地點(diǎn)x,CabDriver會(huì)松油門（releaseAccelerator）吹菱、踩剎車（pressBrakes）巍虫、停止（stop）Taximeter，結(jié)束行程鳍刷。
? ? ? 一切都發(fā)生于發(fā)給CabDriver的一個(gè)簡(jiǎn)單的driveToLocation:x命令之中占遥。無論兩個(gè)子系統(tǒng)有多么復(fù)雜，它們隱藏于乘客的實(shí)現(xiàn)之外倾剿。因?yàn)镃abDriver是在為出租車子系統(tǒng)中的其他復(fù)雜接口提供了一個(gè)簡(jiǎn)化的接口筷频。CabDriver像“外觀”一樣，處于乘客與出租車子系統(tǒng)之間前痘。
參考代碼地址：https://github.com/zhiyoukaifa/Pattern
總結(jié):
? ? ? ? ? ? ?外觀模式是一個(gè)高頻率使用的設(shè)計(jì)模式凛捏，它的精髓就在于封裝二字。通過一個(gè)高層次結(jié)構(gòu)為用戶提供統(tǒng)一的API入口芹缔，使得用戶通過一個(gè)類型就基本能夠操作整個(gè)系統(tǒng)坯癣，這樣減少了用戶的使用成本，也能夠提升系統(tǒng)的靈活性最欠。
? 優(yōu)點(diǎn)：
? ? ?1.對(duì)客戶屏蔽子系統(tǒng)組件示罗，減少了客戶處理的對(duì)象數(shù)目并使得子系統(tǒng)使用起來更加容易。通過引入外觀模式芝硬，客戶代碼將變得很簡(jiǎn)單蚜点，與之關(guān)聯(lián)的對(duì)象也很少。
? ? ? ?2.實(shí)現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系拌阴，這使得子系統(tǒng)的組件變化不會(huì)影響到調(diào)用它的客戶類绍绘，只需要調(diào)整外觀類即可。
? ? ? 3.降低了大型軟件系統(tǒng)中的編譯依賴性迟赃，并簡(jiǎn)化了系統(tǒng)在不同平臺(tái)之間的移植過程陪拘，因?yàn)榫幾g一個(gè)子系統(tǒng)一般不需要編譯所有其他的子系統(tǒng)。一個(gè)子系統(tǒng)的修改對(duì)其他子系統(tǒng)沒有任何影響纤壁，而且子系統(tǒng)內(nèi)部變化也不會(huì)影響到外觀對(duì)象左刽。
? ? ? ?4.只是提供了一個(gè)訪問子系統(tǒng)的統(tǒng)一入口，并不影響用戶直接使用子系統(tǒng)類酌媒。
? 缺點(diǎn)：
? ? ? ? ?1.外觀類接口膨脹欠痴。由于子系統(tǒng)的接口都有外觀類統(tǒng)一對(duì)外暴露迄靠，使得外觀類的API接口較多，在一定程度上增加了用戶使用成本斋否。
? ? ? ? ?2.不能很好地限制客戶使用子系統(tǒng)類梨水，如果對(duì)客戶訪問子系統(tǒng)類做太多的限制則減少了可變性和靈活性。
? ? ? ? ?3.在不引入抽象外觀類的情況下茵臭，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼疫诽，違背了“開閉原則”。
參考書籍：
? ? ? ? ?《Objective-C編程之道 iOS設(shè)計(jì)模式解析》
? ? ? ? ?《Android源碼設(shè)計(jì)模式解析與實(shí)戰(zhàn)》
參考鏈接：
? ? ? ? ? ?https://www.cnblogs.com/wuchanming/p/4483140.html
