在軟體元件的設計中,如果責任劃分的不清晰，使用承得到的果是隨著需求的變化,子類急劇膨脹,同時充斥著重**，這時候的關鍵是劃清責任。
動機
在某些情況下我們可能會「過度地使用繼承來擴充套件物件的功能」，由
於繼承為型別引入的靜態特質，使得這種擴充套件方式缺乏靈活性；並
且隨著子類的增多（擴充套件功能的增多），各種子類的組合（擴充套件功
能的組合）會導致更多子類的膨脹。
解決問題
如何使「物件功能的擴充套件」能夠根據需要來動態地實現？
同時避免 「擴充套件功能的增多」帶來的子類膨脹問題？從而使得任何「功能擴充套件變 化」所導致的影響將為最低？
將編譯時編譯變成裝配時編譯（執行時編譯）
就是在固有的類基礎上進行拓展和改進（裝飾）
定義
動態（組合）的給乙個物件增加一些額外的職責。就增加功能而言，decorator模式比生成子類（繼承）更為靈活（消除重複**&減少重複個數）
要點總結
1.檔案流和記憶體流不是乙個東西嗎？
2.繼承的命名方式，子類的繼承在父類名字前面加上操作子類的子類以此類推。
3.重構的時候需要盡力消除重複的**
4.設計原則：組合優於繼承
5.構造器的作用是什麼呢？
設計模式（三）之單一職責模式
單一職責模式 rsp 就乙個類而言，應該僅有乙個引起它變化的原因 如果乙個類承擔的職責過多，就相當於把這些職責耦合在一起，乙個職責發生變化可能會削弱或者這個類完成其他職責的能力。這種耦合將會導致脆弱的設計，當發生變化的時候，設計可能遇到了意想不到的破壞。就以我們平常所玩的俄羅斯方塊遊戲來說，假若說我...
設計模式之單一職責原則
關於單一職責原則，我想大家都聽過不少，今天來看看這個原則具體是什麼，有哪些好處使我們需要選擇遵守它呢？一 定義 乙個類只能因為乙個原因而修改。怎麼理解呢？簡單來說，乙個類只能實現一項功能，或者換句話說，乙個類只有乙個職責，只有當這個職責發生變化，它才會被修改，說白了就是乙個類質感乙個類該幹的事。二 ...
設計模式之單一職責原則
首先就名字而言不難想象，單一必定是只能有乙個，而這個乙個指的是什麼呢，那就是乙個職責。而職責通俗易懂來說就是乙個功能，乙個類只能有乙個功能，而如果有兩個及以上的功能就不再符合單一職責原則了。就好比乙個水壺，它的功能就只是裝水，而不存放別的東西，那它就滿足了單一職責原則。優點有複雜度低，或者說簡單明瞭...