設(shè)計(jì)模式詳解--結(jié)構(gòu)型

結(jié)構(gòu)型

概念

將一個(gè)類的接口轉(zhuǎn)換為客戶希望的另外一個(gè)接口曹铃。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作
優(yōu)點(diǎn)
- 將目標(biāo)類和和適配者類解耦铛只，通過引入一個(gè)適配器類來重用現(xiàn)有的適配者類，無需修改原有代碼
- 增加了代碼的透明性和復(fù)用性淳玩，將具體的實(shí)現(xiàn)封裝在適配者類中蜕着，對于客戶端來說是透明的，而且提高了適配者的復(fù)用性
- 靈活性和擴(kuò)展性都比較好蓖乘，通過配置文件嘉抒，可以方便的更換適配器些侍，也可以在不修改原有代碼的基礎(chǔ)上增加新的適配器政模，符合開閉原則
缺點(diǎn)
- 對于java淋样、C#等不支持多重繼承的語言，一次最多只能適配一個(gè)適配者類刊咳，而且目標(biāo)只能是接口芦缰，不能是類，其使用有一定的局限性让蕾，不能將一個(gè)適配者類和它的子類同時(shí)適配到目標(biāo)接口
使用場景★★★★☆
- 需要使用現(xiàn)有的類探孝，而這些類的接口不符合系統(tǒng)的需要
- 想要建立一個(gè)可以重復(fù)使用的類誉裆，用于一些彼此沒有太大關(guān)聯(lián)的類一起工作
  
  適配器.png

概念

將對象組合成樹形結(jié)構(gòu)以表示’部分-整體‘的層次結(jié)構(gòu)足丢。組合模式使得用戶對單個(gè)對象和組合對象的使用具有一致性
優(yōu)點(diǎn)
- 組合模式可以清楚地定義分層次的復(fù)雜對象庇配，表示對象的全部或不分層次捞慌，使得增加新構(gòu)件也變得容易
- 客戶端調(diào)用簡單柬批，客戶端可以一致的使用組合結(jié)構(gòu)或其中單個(gè)對象
缺點(diǎn)
- 使設(shè)計(jì)變得更加抽象氮帐，不是所有方法與葉子對象子類都有關(guān)聯(lián)
- 增加新構(gòu)件可能會產(chǎn)生一些問題上沐。有時(shí)候我們希望一個(gè)容器中只能有某些特定類型的對象，使用組合模式時(shí)不能依賴類型系統(tǒng)來施加這些約束冰更，因?yàn)樗麄兌紒碜韵嗤某橄髮影豪眨仨毻ㄟ^在運(yùn)行時(shí)進(jìn)行類型檢查來實(shí)現(xiàn)戈盈，實(shí)現(xiàn)過程會變得復(fù)雜
使用場景★★★★☆
- 需要表示一個(gè)對象整體和部分層次塘娶。在這種層次結(jié)構(gòu)中痊夭，希望忽略整體和部分的差異她我，可以一致對待
  
  組合.png

概念

為其他對象提供一種代理以控制對這個(gè)對象的訪問
優(yōu)點(diǎn)
- 代理模式能夠協(xié)調(diào)調(diào)用者和被調(diào)用者番舆，在一定程度上降低了系統(tǒng)的耦合度
缺點(diǎn)
- 在客戶端和真是主題之間增加了代理對象，因此有些類型的代理可能會造成請求處理變慢
- 實(shí)現(xiàn)代理需要額外的工作疏哗，有些代理模式實(shí)現(xiàn)特別復(fù)雜
使用場景★★★★☆

遠(yuǎn)程代理返奉、虛擬代理、保護(hù)代理等

代理.png

概念

動態(tài)地給一個(gè)對象添加一些額外的職責(zé)雷逆，就增加功能來說关面，裝飾模式比生成子類更加靈活
優(yōu)點(diǎn)
- 可以提供比繼承關(guān)系更多的靈活性
- 可以使用不同的裝飾類排列組合等太，創(chuàng)造出很多不同的行為組合
- 具體構(gòu)件類和具體裝飾類可以獨(dú)立變化蛮放，用戶可以靈活新增并自由組合，符合開閉
缺點(diǎn)
- 會產(chǎn)生許多小對象瞻想，增加系統(tǒng)復(fù)雜度
- 比繼承更靈活蘑险，也就意味著比繼承更容易出錯(cuò)岳悟，排錯(cuò)也困難
使用場景★★★☆☆
- 在不影響其他對象的情況下，以動態(tài)呵俏、透明的方式給單個(gè)對象添加指責(zé)
- 不能繼承或者繼承不利于系統(tǒng)擴(kuò)展和維護(hù)時(shí)
  
  裝飾.png

概念

為子系統(tǒng)中的一組接口提供一個(gè)一致的界面普碎，此模式定義了一個(gè)高層接口录平，這個(gè)接口使得這一子系統(tǒng)更加容易使用
優(yōu)點(diǎn)
- 完美地體現(xiàn)了依賴倒置原則和迪米特法則的思想
- 對客戶屏蔽子系統(tǒng)組件斗这。客戶端代碼變得較少枣察，與之關(guān)聯(lián)的對象也很少
- 實(shí)現(xiàn)了子系統(tǒng)與客戶端的松耦合，降低了編譯依賴性
缺點(diǎn)
- 在不引入抽象外觀類的情況下臂痕，新增子系統(tǒng)時(shí)可能需要修改外觀類或客戶端的源代碼
使用場景★★★★★
- 為復(fù)雜系統(tǒng)提供簡單接口
- 客戶程序與多個(gè)子系統(tǒng)之間存在很大的依賴性
- 在層次化結(jié)構(gòu)中握童，可以使用外觀模式定義系統(tǒng)中每一層的入口澡绩，層與層之間通過外觀類建立聯(lián)系肥卡，降低層之間的耦合度
  
  外觀.png

概念

將抽象部分與它的實(shí)現(xiàn)分離事镣，使他們可以獨(dú)立地變化
優(yōu)點(diǎn)
- 分離抽象接口及其實(shí)現(xiàn)部分璃哟，使其可以沿著各自的維度來變化
- 橋接模式提高了系統(tǒng)的可擴(kuò)展性随闪，在兩個(gè)變化維度人以擴(kuò)展，都不需要修改原系統(tǒng)
缺點(diǎn)
- 增加系統(tǒng)的理解和設(shè)計(jì)難度
- 橋接模式要求正確識別出系統(tǒng)中兩個(gè)獨(dú)立變化的維度障般，因此其適用范圍有一定的局限性
使用場景★★★☆☆
- 一個(gè)類存在兩個(gè)獨(dú)立變化的維度，且這兩個(gè)維度都需要擴(kuò)展
- 如果系統(tǒng)想要在抽象化角色和具體化角色之間增加更多的靈活性即供，避免在兩個(gè)層次之間建立靜態(tài)的繼承關(guān)系
  
  橋接.png

概念

運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對象
優(yōu)點(diǎn)
- 它可以極大減少內(nèi)存中對象的數(shù)量逗嫡，使得相同或相似對象在內(nèi)存中只保存一份
- 享元模式外部狀態(tài)相互獨(dú)立驱证，而且不會影響內(nèi)部狀態(tài)抹锄，，從而享元模式可以被不同環(huán)境共享
缺點(diǎn)
- 享元模式使得系統(tǒng)更加復(fù)雜获高，需要分離出內(nèi)部狀態(tài)和外部狀態(tài)念秧，邏輯復(fù)雜化
- 為了是對象可以共享，享元模式需要將享元對象的狀態(tài)外部化摊趾，而讀取外部狀態(tài)使得運(yùn)行時(shí)間變長
使用場景★☆☆☆☆
- 一個(gè)系統(tǒng)擁有大量相同或相似的對象砾层，由于這些對象的大量使用梢为，造成內(nèi)存的大量耗費(fèi)
- 對象的大部分狀態(tài)都可以外部化轰坊，可以將這些外部狀態(tài)傳入對相愛那個(gè)中
- 需要維護(hù)一個(gè)存儲享元對象的享元池肴沫，這需要耗費(fèi)資源颤芬，因此當(dāng)多次重復(fù)使用享元對象時(shí)，才值得用享元模式
  
  享元.png