本篇是四部曲的第二篇湾笛，第一篇請點這里iOS設(shè)計模式四部曲(一):創(chuàng)建型模式 內(nèi)附Demo妖爷，關(guān)于設(shè)計模式強烈推薦圖書《Head First設(shè)計模式》以及《研磨設(shè)計模式》竟秫。由于個人能力有限晃虫，文中難免有一些遺漏或者錯誤迄汛，請各位看官不吝賜教！謝謝槽畔！本文所有Demo可以在我的Git上獲取栈妆，請點擊這里

第二篇來了

設(shè)計模式.png

廢話不多說，上圖是整個設(shè)計模式的目錄厢钧，這篇文章是其中的第二部分：結(jié)構(gòu)型模式鳞尔。結(jié)構(gòu)型模式包括：適配器模式（Adapter），橋接模式（Bridge）早直，裝飾器模式（Decorator）寥假，組合模式（Composite），外觀模式（Facade）霞扬，享元模式（Flyweight）糕韧，代理模式（Proxy）。下面我們就開始吧~

適配器模式（Adapter）：

1.定義: 適配器模式將一個類的接口變成調(diào)用者所期待的另一種接口喻圃，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作萤彩。(舉一個現(xiàn)實中的實例：比如轉(zhuǎn)接頭)。
2. 使用場景： 擴展應(yīng)用或者組件時斧拍，而被集成進來的又不符合現(xiàn)在的接口雀扶，這個時候可以考慮使用適配器模式。
3. 具體實現(xiàn)： 這里用舉一個實際的例子肆汹，同聲傳譯愚墓。舉了一個虛擬的國際大會場景窍侧，主持人只會說英語，然后馬云先生又聽不懂英語（當然只是假設(shè)转绷，事實是說的比中文都6），在喬布斯演講之后硼啤，就到馬云演講议经，這個時候就需要一個翻譯，去告訴馬云可以開始你的表演啦??谴返，具體Demo點擊這里查看
4.優(yōu)點： 通過使用適配器讓不兼容的接口變成了兼容煞肾，讓調(diào)用者從實現(xiàn)類的接口解耦。在不修改原有代碼的基礎(chǔ)上增加新的適配器類嗓袱，所以靈活性和擴展性比較好籍救，哪天不想用了，就一起卸載掉渠抹。
5.缺點： 只有集成具有類似功能的組件時蝙昙，適配器模式才具有使用價值。具有相似功能具體指：API不一樣梧却，但是功能是相似的奇颠。
6.注意事項: 適配器模式一般不是為了解決還處在于開發(fā)階段的問題，一般都是解決正在服役項目的擴展問題放航。

橋接模式（Bridge）：

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

裝飾器模式（Decorator）：

1.定義: 裝飾模式能動態(tài)的給一個對象添加一些額外的職責歌焦。就增加功能來說飞几，裝飾模式會比通過繼承生成子類更為靈活。
2. 使用場景： 需要動態(tài)地給一個對象增加功能独撇，這些功能也可以動態(tài)地被撤銷屑墨。
3. 具體實現(xiàn)： Objective-C中的Category 就是裝飾器模式的一種應(yīng)用。這里舉了一個雞肉堡的例子纷铣，具體Demo點擊查看
4.優(yōu)點： 裝飾器模式中定義的行為卵史，能夠在不創(chuàng)建大量子類的情況下，組合起來實現(xiàn)復(fù)雜的效果搜立，比繼承更加靈活以躯。
5.缺點： 裝飾器模式會導(dǎo)致設(shè)計中出現(xiàn)許多的小對象，會讓系統(tǒng)變得更加復(fù)雜啄踊，比如說出錯調(diào)試時尋找錯誤可能需要逐級排查忧设。

組合模式（Composite）：

1.定義: 組合模式將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)，使得用戶對單個對象和組合對象的使用具有一致性社痛。
2. 使用場景： 維護和展示部分-整體關(guān)系的場景见转，在具有整體和部分的層次結(jié)構(gòu)中，希望通過一種方式忽略整體與部分的差異蒜哀，可以一致地對待它們的時候斩箫。
3. 具體實現(xiàn)： 這里舉一個文件系統(tǒng)的例子

4.優(yōu)點： 1.高層模塊調(diào)用簡單乘客。2.節(jié)點自由增加，而不必更改原來代碼淀歇。3.葉子對象可以被組合成更復(fù)雜的容器對象易核，而這個容器對象又可以被組合，這樣不斷遞歸下去浪默，可以形成復(fù)雜的樹形結(jié)構(gòu)牡直。
5.缺點： 使設(shè)計變得更加抽象，對象的業(yè)務(wù)規(guī)則如果很復(fù)雜纳决，則實現(xiàn)組合模式具有很大挑戰(zhàn)性碰逸，而且不是所有的方法都與葉子對象子類都有關(guān)聯(lián)。
6.注意事項: 當使用這個屬性結(jié)構(gòu)的調(diào)用組件能夠通過同一個類或者協(xié)議來使用書中包含的所有的對象時阔加，才能證明正確的實現(xiàn)了此模式饵史。

外觀模式（Facade）：

1.定義: 外觀模式要求一個子系統(tǒng)的外部與內(nèi)部的通信必須通過一個統(tǒng)一的對象進行。外觀模式提供一個高層次的接口，用來訪問子系統(tǒng)中的一群接口胳喷。
2. 使用場景： 當一個復(fù)雜子系統(tǒng)需要提供一個簡單的調(diào)用接口時可以使用外觀模式湃番。
3. 具體實現(xiàn)： 外觀模式比較容易理解，這里舉一個家電管家的例子吭露，命令起床吠撮，命令睡覺。家電管家?guī)湍阕鲫P(guān)燈讲竿，拉窗簾等等一系列操作纬向。具體Demo請點擊這里查看
4.優(yōu)點： 使用此模式可以將復(fù)雜的API代碼隱藏到一個簡單的接口中，減少調(diào)用者直接對復(fù)雜API的依賴和耦合戴卜。修改時也只需要修改簡單的接口即可。
5.缺點： 不太遵守開閉原則琢岩，一旦發(fā)現(xiàn)有一些操作的時候投剥，或者在增加新的子系統(tǒng)的時候，可能需要修改外觀類代碼担孔，可能會造成一些風險江锨。

享元模式（Flyweight）：

1.定義: 享元模式就是運行共享技術(shù)有效地支持大量細粒度對象的復(fù)用
2. 使用場景： 系統(tǒng)中存在大量的相似對象，由于這類對象的大量使用可能會造成系統(tǒng)內(nèi)存資源浪費糕篇，而且這些對象的狀態(tài)大部分可以外部化啄育，這個時候可以考慮享元模式。在iOS中拌消，我們用到的UITableView 重用機制就是享元模式的典型應(yīng)用挑豌。
3. 具體實現(xiàn)： 這里通過了一個畫圓的Demo來演示一下享元模式，具體Demo請點擊這里查看
4.優(yōu)點： 通過共享極大的減少了對象實例的個數(shù)墩崩，節(jié)省了內(nèi)存開銷氓英。
5.缺點： 1.提高了系統(tǒng)的復(fù)雜度，需要分離出外部狀態(tài)和內(nèi)部狀態(tài)鹦筹。 2.這些類必須有一個工廠對象加以控制铝阐。

代理模式（Proxy）：

1.定義: 代理模式為其他對象提供一種代理以控制對這個對象的訪問。
2. 使用場景： 想在訪問一個類時做一些控制铐拐。
3. 具體實現(xiàn)： 這里舉一個實際的例子徘键，就是火車票代售點，具體實現(xiàn)Demo請點擊這里查看
4.優(yōu)點： 1遍蟋、職責清晰吹害。 2、高擴展性匿值。
5.缺點： 增加了系統(tǒng)的復(fù)雜度
6.注意事項: 1赠制、和適配器模式的區(qū)別：適配器模式主要改變所考慮對象的接口，而代理模式不能改變所代理類的接口。 2钟些、和裝飾器模式的區(qū)別：裝飾器模式為了增強功能烟号，而代理模式是為了加以控制。

EOF:這篇文章通過Demo梳理了設(shè)計模式中的結(jié)構(gòu)型模式政恍，由于個人能力有限汪拥，難免有一些遺漏或者錯誤，還請各位看官不吝賜教篙耗！ 最近工作有點忙迫筑，剩下的部分會盡量抽時間早點完成。本文已同步到個人博客宗弯，歡迎關(guān)注脯燃，歡迎點贊，歡迎star蒙保，歡迎一起交流辕棚，一起進步！??