本篇是四部曲的第二篇，第一篇請點這里iOS設計模式四部曲(一):創建型模式 內附Demo，關于設計模式強烈推薦圖書《Head First設計模式》以及《研磨設計模式》。由于個人能力有限，文中難免有一些遺漏或者錯誤，請各位看官不吝賜教！謝謝！本文所有Demo可以在我的Git上獲取，請點擊這里

第二篇來了

設計模式.png

廢話不多說，上圖是整個設計模式的目錄，這篇文章是其中的第二部分：結構型模式。結構型模式包括：適配器模式（Adapter），橋接模式（Bridge），裝飾器模式（Decorator），組合模式（Composite），外觀模式（Facade），享元模式（Flyweight），代理模式（Proxy）。下面我們就開始吧~

適配器模式（Adapter）：

1.定義: 適配器模式將一個類的接口變成調用者所期待的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。(舉一個現實中的實例：比如轉接頭)。
2. 使用場景： 擴展應用或者組件時，而被集成進來的又不符合現在的接口，這個時候可以考慮使用適配器模式。
3. 具體實現： 這里用舉一個實際的例子，同聲傳譯。舉了一個虛擬的國際大會場景，主持人只會說英語，然后馬云先生又聽不懂英語（當然只是假設，事實是說的比中文都6），在喬布斯演講之后，就到馬云演講，這個時候就需要一個翻譯，去告訴馬云可以開始你的表演啦??，具體Demo點擊這里查看
4.優點： 通過使用適配器讓不兼容的接口變成了兼容，讓調用者從實現類的接口解耦。在不修改原有代碼的基礎上增加新的適配器類，所以靈活性和擴展性比較好，哪天不想用了，就一起卸載掉。
5.缺點： 只有集成具有類似功能的組件時，適配器模式才具有使用價值。具有相似功能具體指：API不一樣，但是功能是相似的。
6.注意事項: 適配器模式一般不是為了解決還處在于開發階段的問題，一般都是解決正在服役項目的擴展問題。

橋接模式（Bridge）：

1.定義: 橋接模式就是將抽象部分和實現部分解耦，從而使得兩者可以獨立的變化。
2. 使用場景： 重用性要求較高的不希望或不適用使用繼承的場景。也就是說當繼承N層，達到層級有點爆炸的時候可以考慮使用此模式。
3. 具體實現： 這里舉了一個App不同模塊可以切換不同主題的例子，橋接模式主打的是組合優于繼承，具體Demo點擊查看，如果沒有用橋接模式的話，可能就會出現MyRedModule，MyBlueModule這樣的類
4.優點： 此模式分離了應用的抽象部分與實現部分，有利于擴充。
5.缺點： 橋接模式要求正確識別出系統中兩個獨立變化的維度，因此其使用范圍具有一定的局限性。
6.注意事項: 并不是一涉及繼承就要考慮使用橋接模式，不然還要繼承做什么？橋接模式的目的就是要對變化進行封裝，盡可能的把變化的因素封裝到最細最小的單元中，避免風險擴散。所以當發現類的繼承有N層的時候，才需要去考慮使用該模式。

裝飾器模式（Decorator）：

1.定義: 裝飾模式能動態的給一個對象添加一些額外的職責。就增加功能來說，裝飾模式會比通過繼承生成子類更為靈活。
2. 使用場景： 需要動態地給一個對象增加功能，這些功能也可以動態地被撤銷。
3. 具體實現： Objective-C中的Category 就是裝飾器模式的一種應用。這里舉了一個雞肉堡的例子，具體Demo點擊查看
4.優點： 裝飾器模式中定義的行為，能夠在不創建大量子類的情況下，組合起來實現復雜的效果，比繼承更加靈活。
5.缺點： 裝飾器模式會導致設計中出現許多的小對象，會讓系統變得更加復雜，比如說出錯調試時尋找錯誤可能需要逐級排查。

組合模式（Composite）：

1.定義: 組合模式將對象組合成樹形結構以表示“部分-整體”的層次結構，使得用戶對單個對象和組合對象的使用具有一致性。
2. 使用場景： 維護和展示部分-整體關系的場景，在具有整體和部分的層次結構中，希望通過一種方式忽略整體與部分的差異，可以一致地對待它們的時候。
3. 具體實現： 這里舉一個文件系統的例子

4.優點： 1.高層模塊調用簡單。2.節點自由增加，而不必更改原來代碼。3.葉子對象可以被組合成更復雜的容器對象，而這個容器對象又可以被組合，這樣不斷遞歸下去，可以形成復雜的樹形結構。
5.缺點： 使設計變得更加抽象，對象的業務規則如果很復雜，則實現組合模式具有很大挑戰性，而且不是所有的方法都與葉子對象子類都有關聯。
6.注意事項: 當使用這個屬性結構的調用組件能夠通過同一個類或者協議來使用書中包含的所有的對象時，才能證明正確的實現了此模式。

外觀模式（Facade）：

1.定義: 外觀模式要求一個子系統的外部與內部的通信必須通過一個統一的對象進行。外觀模式提供一個高層次的接口，用來訪問子系統中的一群接口。
2. 使用場景： 當一個復雜子系統需要提供一個簡單的調用接口時可以使用外觀模式。
3. 具體實現： 外觀模式比較容易理解，這里舉一個家電管家的例子，命令起床，命令睡覺。家電管家幫你做關燈，拉窗簾等等一系列操作。具體Demo請點擊這里查看
4.優點： 使用此模式可以將復雜的API代碼隱藏到一個簡單的接口中，減少調用者直接對復雜API的依賴和耦合。修改時也只需要修改簡單的接口即可。
5.缺點： 不太遵守開閉原則，一旦發現有一些操作的時候，或者在增加新的子系統的時候，可能需要修改外觀類代碼，可能會造成一些風險。

享元模式（Flyweight）：

1.定義: 享元模式就是運行共享技術有效地支持大量細粒度對象的復用
2. 使用場景： 系統中存在大量的相似對象，由于這類對象的大量使用可能會造成系統內存資源浪費，而且這些對象的狀態大部分可以外部化，這個時候可以考慮享元模式。在iOS中，我們用到的UITableView 重用機制就是享元模式的典型應用。
3. 具體實現： 這里通過了一個畫圓的Demo來演示一下享元模式，具體Demo請點擊這里查看
4.優點： 通過共享極大的減少了對象實例的個數，節省了內存開銷。
5.缺點： 1.提高了系統的復雜度，需要分離出外部狀態和內部狀態。 2.這些類必須有一個工廠對象加以控制。

代理模式（Proxy）：

1.定義: 代理模式為其他對象提供一種代理以控制對這個對象的訪問。
2. 使用場景： 想在訪問一個類時做一些控制。
3. 具體實現： 這里舉一個實際的例子，就是火車票代售點，具體實現Demo請點擊這里查看
4.優點： 1、職責清晰。 2、高擴展性。
5.缺點： 增加了系統的復雜度
6.注意事項: 1、和適配器模式的區別：適配器模式主要改變所考慮對象的接口，而代理模式不能改變所代理類的接口。 2、和裝飾器模式的區別：裝飾器模式為了增強功能，而代理模式是為了加以控制。

EOF:這篇文章通過Demo梳理了設計模式中的結構型模式，由于個人能力有限，難免有一些遺漏或者錯誤，還請各位看官不吝賜教！ 最近工作有點忙，剩下的部分會盡量抽時間早點完成。本文已同步到個人博客，歡迎關注，歡迎點贊，歡迎star，歡迎一起交流，一起進步！??