1.問題的引入：
有時候我們需要動態地擴充套件物件的功能。比如現在給快餐店編寫一選單程式。主食和菜品可以互相搭配，我們要怎麼確立餐廳需要的各種選單類呢？
首先我們嘗試下類的繼承能不能解決問題：
主食和菜是兩個介面，任何乙個選單裡面都應該搭配主食和菜，那我們就把所有的搭配都定義成類。選單是乙個實現了這兩個介面的超類，任何一種特定的主食+菜式搭配都可以定義乙個新類，繼承選單這個超類就可以了。
這樣寫肯定是會被老大罵的，主食和菜式特別多的時候，類的數量級也特別大。維護量太大。三種主食，20種菜的話就是六十個類。哪天新加一種主食，開發得寫20個類，還是在乙個主食只能搭配一種菜式這種最簡單的情況下，不利於擴充套件，pass掉。
其次我們再來看看組合能不能解決問題：
畢竟選單是由主食和各色菜式搭配的麼？那我們的選單類應該是這樣的：
這種組合的設計至少沒有類的氾濫，老大不會馬上罵你的。現在我們來看看還有什麼問題？ 首先，order裡面定義了三個菜式的屬性，那麼就意味著乙個使用者最多只能吃三樣菜。多了我們就不支援了，可能大多情況下，我們吃快餐只要乙份菜，那麼另外兩個為空，在計算**和獲取菜式的描述的方法裡面，我們還是要考慮可能為空的值。說白了，能解決問題，但是**還是不夠簡潔。每次都要檢查非空，也的確不是很合理。
那麼有沒有更加智慧型的解決方法呢？下面我們就引出裝飾者模式。
2. 裝飾者模式：
動態給乙個物件新增一些額外的職責。
就上面的問題，物件就是主食，額外的職責就是那些各式各樣的菜色。下面我們來看下類圖：
在上面的類圖我們可以看到，被裝飾的主題即各種主食和所謂的裝飾者（各色菜式）是同源的，他們都實現了同乙個介面，當然你也可以設計成乙個抽象類。我們前面講了，不是不用繼承麼？ 這裡的繼承和前面的繼承是有本質的區別的。前面是為了繼承某乙個功能就繼承那個類，所以最後類氾濫了。但是在觀察者模式裡面，繼承是為了方便裝飾。你是乙個主食，我裝飾你之後，就變成了主食加某種菜式。但是不需要把這種裝飾的組合維護成一種類。所以在裝飾者模式裡面，不會類氾濫。因為主食和菜式解耦了，所以動態新增各種菜式也變成了可能。
3.**實現：
現在在來看下測試**和執行結果：
執行結果：
看看測試**，我們先用白菜裝飾公尺飯，相當於是乙個公尺飯配白菜的選單，後面又用蘿蔔繼續裝飾，就是白菜蘿蔔加公尺飯的選單。現在明白了，為什麼裝飾者和被裝飾者要是同源了的吧？動態裝飾，這樣設計，如果乙個人想吃一百種菜我們也能解決。哈哈~~~ 前提的是他的胃容量足夠大。
Head First 設計模式讀書心得 一
head first 設計模式這本書，從思維認知的角度將原本難以理解和記識的設計模式將得通俗易懂。雲認知 有關思考的思考 如何你想掌握一些知識，學習前要不短的暗示自己，讓你的大腦知道 你學習的這些新的知識很重要 或許你正在為一家你嚮往已經的公司的面試準備寫知識，你將要學習的這些知識對你通過面試至關重...
head first設計模式讀書記錄
設計原則 1 針對介面程式設計而非針對實現 2 多用組合，少用繼承 3 復用的潛力 4 封裝變化 5 開閉原則 對擴充套件開放，對修改關閉 6 依賴倒置原則 7 越常用，越不應修改，把可能的修改扔給必須要改的部分，最好扔給擴充套件。封裝變化 8 最少知識原則 減少類與類的重合，只與密友交流 9 越懶...
《Head First 設計模式》讀書筆記
策略模式 定義演算法族，分別封裝起來，讓他們之間可以互相替換，此模式讓演算法的變化獨立於使用演算法的客戶。oo原則 封裝變化 多用組合，少用繼承 針對介面程式設計，不針對實現程式設計 oo基礎 抽象封裝 多型繼承 觀察者模式 在物件之間定義一對多的依賴，這樣一來，當乙個物件改變狀態，依賴它的物件都會...