HeadFirst設計模式 讀書筆記1

我們已經搬到對象村，剛剛開始着手設計模式……這裏每個人都在使用設計模式。很快我們就會通過設計模式躋身上流社會。
    設計原則：找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。   
    把會變化的部分取出並封裝起來，好讓其他部分不會受到影響。   
    結果如何？代碼變化引起的不經意後果變少，系統變得更有彈性。
    設計原則：針對接口編程，而不是針對實現編程。
    從現在開始，鴨子的行爲將被放在分開的類中，此類專門提供某行爲接口的實現。
    這樣，鴨子類就不再需要知道行爲的實現細節。
    針對接口編程真正的意思是"針對超類型supertype編程"
    設計原則：多用組合，少用繼承。
    策略模式
       定義了算法族，分別封裝起來，讓它們之間可以相互替換，此模式讓算法的變化獨立於使用算法的客戶。
    良好的OO設計必須具備可複用、可擴展、可維護三個特性。

喂，Jerry，我正在通知大家，模式小組會議改到週六晚上，這次討論的是觀察者模式，這個模式最棒了！超級棒！你一定要來呀，Jerry。
    觀察者模式
       定義了對象之間的一對多依賴，這樣以來，當一個對象改變狀態時，它的所有依賴者都會收到通知並自動更新。
    設計原則：爲了交互對象之間的鬆耦合設計而努力。
    要點
       觀察者模式定義了對象之間的一對多關係。
       主題，也就是可觀察者用一個共同的接口來更新觀察者。
       觀察者和可觀察者之間用鬆耦合方式結合，可觀察者不知道觀察者的細節，只知道觀察者實現了觀察者接口。
       使用此模式時，你可從被觀察者處推push或拉pull數據，然而，推的方式被認爲更正確。
       有多個觀察者時，不可以依賴特定的通知次序。
       Java有多種觀察者模式的實現，包括了通用java.util.Observable
       要注意java.util.Observable實現上所帶來的一些問題。
       如果有必要的話，可以實現自己的Observable，這並不難，不要害怕。
       Swing大量使用了觀察者模式，許多GUI框架也是如此。
       此模式也被應用在許多地方。例如：JavaBeans、RMI。

我曾經以爲男子漢應該用繼承處理一切。後來我領教到運行時擴展，遠比編譯時期的繼承威力大。看看我現在光彩的樣子。
    裝飾模式
       動態地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更有彈性的替代方案。
    設計原則：類應該對擴展開發，對修改關閉。   
    要點1
       裝飾者和被裝飾者對象有相同的超類型。
       你可以用一個或多個裝飾者包裝一個對象。
       既然裝飾者和被裝飾對象有相同的超類型，所以在任何需要原始對象（被包裝）的場合，可以用裝飾過的對象代替它。
       裝飾者可以在所委託被裝飾者的行爲之前與/或之後，加上自己的行爲，以達到特定的目的。
       對象可以在任何時候被裝飾，所以可以在運行時動態地、不限量地用你喜歡的裝飾者來裝飾對象。
    要點2
       繼承屬於擴展形式之一，但不見得是達到彈性設計的最佳方案。
       在我們的設計中，應該允許行爲可以被擴展，而無須修改現有的代碼。
       組合和委託可用於在運行時動態地加上新的行爲。
       除了繼承，裝飾者模式也可以讓我們擴展行爲。
       裝飾者模式意味着一羣裝飾者類，這些類用來包裝具體組件。
       裝飾者類反映出被裝飾的組件類型（他們具有相同的類型，都經過接口或繼承實現）
       裝飾者可以在被裝飾者的行爲前面與/或後面加上自己的行爲，甚至將被裝飾者的行爲整個取代掉，而達到特定的目的。
       你可以用無數個裝飾者包裝一個組件。
       裝飾者一般對組件的客戶是透明的，除非客戶程序依賴於組件的具體類型。
       裝飾者會導致設計中出現許多小對象，如果過度使用，會讓程序變得很複雜。