在將模式之前，先對乙個oo設計原則掌握
對擴充套件開放和對修改關閉
無論如何，程式不能因為一些功能的修改就去該原來寫的，這樣只會越改越亂，因此，對修改遮蔽，和新增加的功能使用擴充套件的方式新增進去
裝飾者模式正可以做到這一點。這裡碰到的問題就是，軟體應對變化的能力，裝飾者模式提高了軟體的彈性，增加了可維護性
到底是怎麼做到的呢？
首先來看個例項，有個咖啡廳提供乙個計價的軟體，怎麼才能描述各種咖啡飲料**，
這裡可以設計乙個berverge的父類，提供各個子類就行了
然而當飲料的各種配料也要計價進去時怎麼辦？？
不可能為每個飲料和配料組成寫個類 ----------瘋了
當然你可以將所有的配料加入berverge中，返回他們的**，並在cost（）時加入要加的配料**，這裡也有個problem：對於將來加入的新的配料，需要修改原始碼就違反了先前說的
oo原則
那怎麼辦？
裝飾者模式，就是在執行時動態的加入新的行為的一種設計模式。
首先，對於berverge類提供各種配料的封裝
class berverge
class moka extends berverge
public double cost()
}裝飾在那裡？？
在一杯摩卡咖啡時，只要提供乙個moka的berverge對乙個咖啡的封裝就行了
如 new moka(new coffee()).cost();//這樣就能得到一杯摩卡咖啡的**了
裝飾模式是如何做到這一點的？？
繼承，早就知道通過繼承能夠得到物件的行為的復用，但是，這裡的繼承是對型別的繼承 ， 為什麼，因為moka 和coffee都來自於berverge類，因此可以在moka中
做到對行為的動態變化，moka呼叫coffee的行為，並在呼叫此行為的前後增加自己的行為
這裡這個問題就解決了
可以通過提供各種配料的berverge子類，當需要的什麼飲料和不論多少配料時，只要不停的裝飾就行了（多個裝飾物件裝飾乙個元件）
new xx(new xx(new xx...))這樣就能得到所有組合的**
同有新的飲料或配料時，也沒有問題，只要新增相應的類，使用時裝飾進去就行了
（可見裝飾模式對變化有很好的彈性）
那裝飾模式有什麼不足嗎？？？
首先裝飾模式，意味著一些不同就是乙個小類，可能會造成類很多
然後 當你使用的類有特殊的行為時，裝飾模式為出錯，它只能處理berverge中的普變行為（normal)
最後 就是 裝飾者的得到非常複雜（初始化，有很多的new），工廠模式和builder模式也許能解決這個問題，我學到時再將
jdk中的裝飾
最好的體現就是io
filterinputstream就是io中所有裝飾類的父類
你可以同繼承它來實現自己的io類，封裝一些讀取時的行為，比如大小寫轉換等，見例：
class lowcaseinputstream extends filterinputstream
public int read()
public byte read(byteb , int start, int len)}}
設計模式學習筆記（三 裝飾模式）
在許多設計中，可能需要改進類的某個物件的功能，而不是該類建立的全部物件，在這樣的情況下，就可以使用裝飾模式。例如，麻雀類的例項 麻雀 能夠連續飛行100公尺，如果用麻雀類建立了5只麻雀，那麼這5只麻雀都能連續飛行100公尺。假如想讓其中乙隻麻雀能夠連續飛行150公尺，那應當怎樣做呢？一種比較好的辦法...
設計模式 三 裝飾模式
動態地給乙個物件新增一些額外的職責 不重要的功能，只是偶然一次要執行 就增加功能來說，裝飾模式比生成子類更為靈活。建造過程不穩定，按正確的順序串聯起來進行控制。good 當你向舊的類中新增新 時，一般是為了新增核心職責或主要行為。而當需要加入的僅僅是一些特定情況下才會執行的特定的功能時 簡單點就是不...
設計模式 裝飾模式（三）
裝飾模式 軟體領域中的設計模式的重要性不言而喻。設計模式中運用了物件導向程式設計語言的重要特性 封裝 繼承 多型。雖然知道這些特性的定義但是並沒有做到真正的理解，這樣特性有什麼作用？用於什麼場合中等等問題，帶著疑問開始學習設計模式，主要參考 大話設計模式 和 設計模式 可復用物件導向軟體的基礎 兩本...