Head First 設計模式 筆記

設計模式定義：

1，策略模式。定義了演算法族，分別封裝起來，讓它們之間可以互相替換，此模式讓演算法的變化獨立於使用演算法的客戶。

2，觀察者模式。定義了對象之間的一對多依賴，這樣一來，當一個對象改變狀態時，它的所有依賴者都會收到通知並自動更新。

3，裝飾者模式。動態地將責任附加到對象上。若要擴充功能，裝飾者提供了比繼承更有彈性的替代方案。

4，Factory 方法模式。定義了一個建立對象的介面，但由子類決定要執行個體化的類是哪一個。Factory 方法讓類把執行個體化延遲到子類。

5，抽象原廠模式。提供一個介面，用於建立相關或依賴對象的家族，而不需要明確指定具體類。

6，單件模式。確保一個類只有一個執行個體，並提供一個全域訪問點。

7，命令模式。將“請示”封裝成對象中，以便使用不同的請示，隊列或者日誌來參數化其它對象。命令模式也支援可撤銷的操作。

8，適配器模式。將一個類的介面，轉換成客戶期望的另一個介面。適配器讓原本介面不相容的類可以合作無間。

9，面板模式。提供了一個統一的介面，用來訪問子系統中的一群介面。外觀定義了一個高層介面，讓子系統更容易使用。

10，模板方法模式。在一個方法中定義一個演算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以在不改變演算法結構的情況下，重新定義演算法中的某些步驟。

11，迭代器模式。提供一種方法順序訪問一個彙總對象中的各個元素，而又不暴露其內部的表示。

12，組合模式。允許你將對象組合成樹形結構來表現“整體/部分”階層。組合能讓客戶以一致的方式處理個雖對象以及對象組合。

13，狀態模式。允許對象在內部狀態改變時改變它的行為，對象看起來好像修改了它的類。

14，代理模式。為另一個對象提供一個替身或預留位置以控制對這個對象的訪問。

15，複合模式。結合兩個或以上的模式，組成一個解決方案，解決一再發生的一般性問題。

設計原則：

1，找出應用中可能需要變化之處，反它們獨立出來，不要和那些不需要變化的代碼混在一起。

2，針對介面編程，而不是針對實現編程。

3，多用組合，少用繼承。

4，為了互動對象之間的松藕合設計而努力。

5，類應該對擴充開放，對修改關閉。

6，要依賴抽象，不要依賴具體類。

7，最少知識原則：只和你的密友談話。

8，好萊塢原則：別調用（打電話給）我們，我們會調用（打電話給）你。

9，一個類應該只有一個引起變化的原因。

設計基礎：

1，抽象。

2，封裝。

3，多態。

4，繼承。

要點：

一：

1，知道OO基礎，並不足以讓你設計出良好的OO系統。

2，良好的OO設計必須具備可複用，可擴充，可維護三個特性。

3，模式可以讓我們建造出具有良好OO設計品質的系統。

4，模式被認為是曆經驗 證的OO設計經驗。

5，模式不是代碼，而是針對設計問題的通用解決方案。你可把它們應用到特定的應用中。

6，模式不是被發明，而是被發現。

7，大多數的模式和原則，都著眼於軟體變化的主題。

8，大多數的模式都允許系統局部改變獨立於其他部分。

9，我們常把系統中會變化的部分抽出來封裝。

10，模式讓開發人員之間有共用的語言，能夠最大化溝通的價值。

二：

1，觀察者模式定義了對象之間一對多的關係。

2，主題（也就是可觀察者）用一個共同的介面來更新觀察者。

3，觀察者和可觀察者之間用松耦合方式結合，可觀察者不知道觀察者的細節只知道觀察者實現了觀察者介面。

4，使用此模式時，你可從被觀察者處推（push）或拉（pull）資料（然而，推的方式被認為更“正確”）。

5，有多個觀察者時，不可以依賴特定的通知次序。

6，Java有多種觀察者模式的實現，包括了通用的java.util.Observable。

7，要注意java.util.Observable實現上所帶來的一些問題。

8，如果有必要的話，可以實現自己的Observable,這並不難，不要害怕。

9，Swing大量使用觀察者模式，許多GUI架構也是如此。

10，此模式也被應用在許多地方，例如：JavaBean，RMI。

三：

1，繼承屬於擴充形式之一，便不見得是達到彈性設計的最佳方式。

2，在我們的設計中，應該允許行為可以被 擴充，而無須修改現有的代碼。

3，組合和委託可用於在運行時動態地加上新的行為。

4，除了繼承，裝飾者模式也可以讓我們擴充行為。

5，裝飾者模式意味著一群裝飾者類，這些類用來封裝具體組件。

6，裝飾者類反映出被裝飾的組件類型（事實上，他們具有相同的類型，都經過介面或繼承實現）。

7，裝飾者可以在被裝飾者的行為前面與/或後面加上自己的行為，甚至將被裝飾者的行為整個取代掉，而達到特定的目的。

8，你可以用無數個裝飾者封裝一個組件。

9，裝飾者一般對組件的客戶是透明的，除非客戶程式依賴於組件的具體類型。

10，裝飾者會導致設計中了現許多小對像，如果過度使用，會讓程式變得很複雜。

四：

1，所有的工廠都是用來封裝對象的建立。

2，簡單工廠，雖然不是真正的設計模式，但仍不失為一個簡單的方法，可以將客戶程式從具體類解耦。

3，Factory 方法使用繼承：把對象的建立委託給子類，子類實現Factory 方法來建立對象。

4，抽象工廠使用對象組合：對象的建立被實現在工廠介面所暴露出來的方法中。

5，所有原廠模式都通過減少應用程式和具體類之間的依賴促進松耦合。

6，Factory 方法允許類將執行個體化延遲到子類進行。

7，抽象工廠建立相關的對象家族，而不需要依賴它們的具體類。

8，依賴倒置原則，指導我們避免依賴具體類型，而要盡量依賴抽象。

9，工廠是很有威力的技巧，協助我們針對抽象編程，而不要針對具體類編程。

五：

1，單件模式確保程式中一個類最多隻有一個執行個體。

2，單件模式也提供訪問這個執行個體的全域點。

3，在Java中實現單件模式需要私人的構造器，一個靜態方法和一個靜態變數。

4，確定在效能和資源上的限制，然後小心地選擇適當的方案來實現單件，以解決多線程的問題（我們必須認定所有的程式都是多線程的）。

5，如果不是採用jdk1.5 及以後的版本，雙重檢查加鎖實現會失效。

6，小心，你如果使用多個類載入器，可能導致單件失效而產生多個執行個體。

7，如果使用JVM 1.2 或 之前的版本，你必須建立單件註冊表，以免垃圾收集器將單件回收。

六：

1，命令模式將發出請求的對象和執行請求的對象解耦。

2，在被解耦的兩者之間是通過命令對象進行溝通的。命令對象封裝了接收者和一個或一組動作。

3，調用者通過調用命令對象的execute()發出請示，這會使得接收者的動作被調用。

4，調用者可以接受命令當做參數，甚至在運行時動態地進行。

5，命令可以支援撤銷，做法是實現一個undo()方法來回到execute()被執行前的狀態。

6，宏命令是命令的一種簡單的延伸，允許調用多個命令。宏方法也可以支援撤銷。

7，實際操作時，很常見使用“聰明”命令對象，也就是直接實現了請求，而不是將工作委託給接收者。

8，命令也可以用來實現日誌和事務系統。

七：

1，當需要使用一個現有的類而其介面並不符合你的需要時，就使用適配器。

2，當需要簡化並統一一個很大的介面或者一群複雜的介面時，使用外觀。

3，適配器改變介面以符合客戶期望。

4，外觀將客戶從一個複雜的子系統中解耦。

5，實現一個適配器可能需要一番功夫，也可能不費功夫，視目標介面的大小與複雜度而定。

6，實現一個外觀，需要將子系統組合進外觀中，然後將工作委託給子系統執行。

7，適配器模式有兩種形式：對角適配器和類適配器。類適配器需要用到多重繼承。

8，你可以為一個子系統實現一個以上的外觀。

9，適配器將一個對象封裝起來以改變其介面；裝飾者將一個對象封裝起來以增加新的行為和責任；而外觀將一群對象“封裝”起來以簡化其介面。

八：

1，“模板方法”定義了算未能的步驟，把這些步驟的實現延遲到子類。

2，模板方法模式為我們提供了一種代碼複用的重要技巧。

3，模板方法的抽象類別可以定義具體方法，抽象方法和鉤子。

4，抽象方法由子類實現。

5，鉤子是一種方法，它在抽象類別中不做事，或者只做預設的事情，子類可以選擇要不要去覆蓋它。

6，為了防止子類改變模板方法中的演算法，可以將模板方法聲明為final。

7，好萊塢原則告訴我們，將決策權放在高層模組中，以便決定如何以及何時調用低層模組。

8，你將在真實世界代碼中看到模板方法模式的許多變體，不要期待它們全都是一眼就可以被你認出的。

9，策略模式和模板方法模式都封裝演算法，一個用組合，一個用繼承。

10，Factory 方法是模板方法的一種特殊版本。

九：

1，迭代器允許訪問彙總的元素，而不需要暴露它的內部結構。

2，迭代器將遍曆彙總的工作封裝進一個對象中。

3，當使用迭代器的時候，我們依賴彙總提供遍曆。

4，迭代器提供了一個通用的介面，讓我們遍曆彙總的項時，就可以使用多態機制。

5，我們應該努力讓一個類只分配一個責任。

6，組合模式提供一個結構，可同時包容個別對象和組合對象。

7，組合模式允許客戶對個別對象以及組合對象一視同仁。

8，組合結構內的任意對象稱為組件，組件可以是組合，也可以是分葉節點。

9，在實現組合模式時，有許多設計上的折衷。你要根據需要平衡透明性和安全性。

十：

1，狀態模式允許一個對象基於內部狀態而擁有不同的行為。

2，和程式狀態機器（PSM）不同，狀態模式用類代表狀態。

3，Context會將行為委託給目前狀態對象。

4，通過將每個狀態封裝進一個類，我們把以後需要做的任何改變局部化了。

5，狀態模式和策略模式有相同的類圖，但是它們的意圖不同。

6，策略模式通常會用行為或演算法來配置Context類。

7，狀態模式允許Context隨著狀態的改變而改變行為。

8，狀態轉換可以由State類或Context類控制。

9，使用狀態模式通常會導致設計中類的數目大量增加。

10，狀態類可以被多個Context執行個體共用。

十一：

1，代理模式為另一個對象提供代表，以便控制客戶對對象的訪問，管理訪問的方式有許多種。

2，遠程代理管理客戶和遠程對象之間的互動。

3，虛擬代理控制訪問執行個體化開銷大的對象。

4，保護代理基於調用者控制對對象方法的訪問。

5，保護模式有許多變體，例如：緩衝代理，同步代理，防火牆代理和寫入時複製代理。

6，代理在結構上類似裝飾者，但是目的不同。

7，裝飾者模式為對象加上行為，而代理則是控制訪問。

8，Java內建的代理支援，可以根據需要建立動態代理，並將所有調用分配到所選的處理器。

9，就和其他的封裝者（wrapper）一樣，代理會造成你的設計中類的數目增加。

十二：

1，MVC是複合模式，結合了觀察者模式，策略模式和組合模式。

2，模型使用觀察者模式，以便觀察者更新，同時保持兩者之間解耦。

3，控制器是視圖的策略，視圖可以使用不同的控制器實現，得到不同的行為。

4，視圖使用組合模式實現使用者介面，使用者介面通常組合了嵌套的組件，像面板，架構和按鈕。

5，這些模式攜手合作，把MVC模型的三層解耦，這樣可以保持設計乾淨又有彈性。

6，適配器模式用來將新的模型適配成已有的視圖和控制器。

7，Model 2是MVC在Web上的應用。

8，在Mode 2中，控制器實現成Servlet，而Jsp/HTML實現視圖。