1.介面卡模式(adapter)
基礎教程
看了《設計模式》和這篇文章，覺得介面卡的乙個重點就是物件所提供的介面並不一定能適應我們的新環境，我們就要對其轉換成我們需要的介面(其實不適應新環境就是類成員函式名稱不一樣，無法通過父類指標直接操作子類)
設計模式裡面有乙個例子就是在程式上繪製幾何圖形的問題，我們有lineshape，polygnshape都繼承自shape，也有統一的介面，比如有個介面boundingbox,現在我們要加入乙個textshape，一般是要自己重新寫乙個，但是已經有程式庫提供了textview經過稍微更改可以滿足我們的需求,但是類的成員函式名跟我們不一致，比如textview有乙個成員函式boundingfun的功能跟boundingbox一樣
這種情況下我一般可以直接使用textview或者創造乙個類textview2，繼承自textview，這個也是我認為比較好的方法，節省時間，又重用**
但是如果我們想可以直接通過shape的指標來操作這個textshape，也就是說我們的客戶只要new了乙個幾何圖形後，不管是lineshape還是textshape，都可以通過一樣的介面去操作，這個時候我們可以讓textshape 以public的方式繼承shape，以private的方式繼承textview,或者有個私有的textview成員變數，這樣我們就可以達到上述的目的
介面卡模式又分為物件介面卡和類介面卡，其實就是乙個通過組合，乙個通過繼承來實現介面卡，當然我更傾向於組合，因為如果我們後面textview有了子類，比如textview2，當我們要對這些類進行適配，如果使用繼承我們就需要再創造乙個類，比如textshape2,但是如果我們使用組合，我們就可以通過給textshape來增加乙個settextview的介面，可以直接通過同樣的介面來操作textview2
裝飾者模式(decorator）:
基礎教程
顧名思義，裝飾者模式就是給類加上一點裝飾，我們有乙個decorator和component，如果我們要對component或者他的基類進行附加操作，那麼我們可以用decorator對component進行裝飾，然後decorator對component的操作進行附加操作，decortor更傾向於改變物件的外殼，而不是strategy傾向於改變物件的核心
《設計模式》裡面有乙個例子，就是textview控制項的問題，textview控制項有乙個父類visualcomponent，textview通過draw來繪製，但是不支援有滾動條，現在我們需要textview有滾動條的功能，那我們該怎麼辦？？
一般我會新建乙個類，名字叫textviewscroll，然後有這樣如果我需要乙個有滾動條的textview控制項，那麼只要新建這個類就可以了，但是如果我們現在有另外乙個控制項，比如list，這個類也是繼承自visualcomponent,這個控制項也需要滾動條，那我們是不是還要再建立乙個textviewscroll??
這個時候我們 就需要乙個裝飾者，就是給textview和list裝飾乙個滾動條，這個時候我們也有乙個裝飾者decorator，這個類繼承自visualcomponent，而且這個類可以接受乙個visualcomponent的類或者子類，當我們需要滾動條的時候，只要讓decorator去裝飾傳入的visualcomponent的類，在draw控制項的時候順便draw滾動條
這個模式有個缺點就是如果被裝飾的物件沒有公共的父類，並且沒有統一的介面，那麼就沒辦法使用裝飾者，只能用我說的那個方法(可能後面有其他的方法，再繼續看看)
享元模式(flyweight)
基礎教程
享元模式給我的感覺更像是另外乙個版本的寫時複製，不同的是更改的時候，比如有三個字串a,b,c，a字串指向"abc"，b指向"bcd"，此時如果c=a，那麼c也指向"abc"，記憶體中實際只有兩個字串"abc"和"bcd"，如果這個時候把c="bcd"，如果是寫時複製，那麼這個時候c會指向"bcd"，但是不是b所指向的"bcd"，是新的記憶體，這樣記憶體中就有三塊記憶體，abc,bcd,bcd，如果是享元模式，那麼c會先在所有可以共享的字串裡面查詢是否有"bcd"，如果有，那麼直接把c指向"bcd"，那樣記憶體中就只有兩塊，"abc"和"bcd"
我的理解就是享元會創造一組可以共享的記憶體，如果我們需要更改一些物件的資料，那麼會先在這些記憶體中查詢，然後直接讓該物件指向共享的記憶體，沒有再進行建立
享元適用於一些有大量重複內容的資料，比如《設計模式》提到的乙個文件編輯器，文件編輯器如果每乙個字元都要用乙個物件儲存的話，那麼對記憶體是很損耗的，但實際上字母也就二十幾個而已，這些字母都是一樣的，只有字元的位置和顏色不一樣，這個時候字元就是 可以共享的，只有位置和顏色不可共享，可以把可共享的提取出來(當然乙個字元指標實際上比乙個字母更耗記憶體，這裡只是舉個例子)
外觀和**(facade，proxy）
說實話我覺得這兩個模式是一樣的，就是再加一層用以掩蓋內部的情況，不過我沒想到share_ptr是**模式
橋接模式(bridge):
橋接模式給我的感覺也是乙個**模式或者說是外觀模式的變種，他們提供給使用者的都只是介面，掩蓋了內部的實現
《設計模式》舉了個例子，就是跨平台的視窗，bridge模式將抽象和實現分離，實現就是windowimp這些，通過windows類裡面的windowsimp指標，根據不同的平台建立不同的類，然後就可以掩蓋window究竟呼叫的是xwindow還是pmwindow的實現，
組合模式(composite):
如上圖，組合模式就是使用者對單個物件還是組合物件的使用都具有一致性，我的理解就是不管是0403這個節點也好，還是04-0401-0402-0403，還是整棵樹，對於使用者提供的介面都是一樣的，使用者不必去關心add或者remove的時候究竟是葉節點還是子樹
看設計模式感覺看得還是挺迷糊的，只能說慢慢去理解，不過設計模式這種東西畢竟還是靠實踐，只能說以後做東西盡量看看能不能使用設計模式，當然只是為了增加經驗而已，千萬不要動不動就設計模式設計模式
看完了這些，感覺結構型模式還是要在知道要做什麼基礎上去使用，否則根本無法把整個架構給設計好，不過目前我還沒到那個水平，只能說盡量把**寫得低耦合，以及可讀性好，這樣後期更改會很容易
設計模式之結構型模式
結構型設計模式主要考慮的是 如何組合類和物件以獲得更大的結構。結構型模式分為兩種 結構型物件模式和結構型類模式 結構型類行為模式 採用繼承機制來組合介面或實現。乙個簡單的例子是採用多重繼承方法將兩個以上的類組合成乙個類，結果這個類包含了所有父類的性質。eg adapter模式 結構型物件行為模式 描...
設計模式之結構型模式
設計模式分為三大類 1 建立型模式，共五種 工廠方法模式 抽象工廠模式 單例模式 建造者模式 原型模式。2 結構型模式，共七種 介面卡模式 裝飾器模式 模式 外觀模式 橋接模式 組合模式 享元模式。3 行為型模式，共十一種 策略模式 模板方法模式 觀察者模式 迭代子模式 責任鏈模式 命令模式 備忘錄...
設計模式 結構型模式
介面卡模式 adapter pattern 橋接模式 bridge pattern 過濾器模式 filter criteria pattern 組合模式 composite pattern 裝飾器模式 decorator pattern 外觀模式 facade pattern 享元模式 flywei...