《Head.First設計模式》的學習筆記（1）

書中列舉了一些讓大腦就範的原則，其實這也是我們在學習中應該遵循的原則。這些原則如下：

1、慢一點，你理解的越多，需要記的就越少。

2、勤做練習，自己記筆記。

3、上床睡覺之前不要再看別的書了，或者至少不再看其他有難度的東西。

4、要喝水，而且要多喝點水。

5、大聲說出來。

6、聽聽你的大腦怎麼說。

7、要有點感覺！

8、設計一點東西！

書中列舉的設計原則：

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

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

舉例說明：

假設有一個抽象類別Animal，有兩個具體的實現（Dog與Cat）繼承Animal。

“針對實現編程”的做法：Dog d = new Dog();d.bark();

“針對介面編程”的做法：Animal animal = new Dog();animal.makeSound();

                                或者：Animal animal = getAnimal();animal.makeSound();

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

原因：

       a、繼承會使類無限膨大，可能會使類變得臃腫。

       b、子類可能會繼承父類中那些無用甚至有害的方法。

       c、組合比繼承更靈活，可以實現在執行中動態改變對象的功能。

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

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

6、要依賴抽象，不要依賴具體類。
解釋：不要讓“高層組件”依賴“低層組件”，而且，不管“高層組件”還是“低層組件”，兩者都應該依賴於抽象。
避免違反該原則的幾個方針：
1）、變數不可以持有具體類的引用。
如果使用new，就會持有具體類的引用，可以使用工廠來避開這種引用。
2）、不要讓類派生自具體類。
如果派生自具體類，就會依賴具體類，可以派生自抽象或介面。
3）、不要覆蓋基類中已實現的方法。
如果覆蓋基類中已實現的方法，那麼基類就不是一個真正適合被繼承的類。基類中已實現的方法應該被所有子類所共用。
7、最少知識原則。
解釋：當你設計一個系統時，不管是任何對象，你都要注意與它互動的類有哪些，並注意它和這些類是如何互動的，盡量避免過多的類別結合程度在一起，帶來維護成本的上升。
這個原則推薦的一些方針：
就任何對象而言，在該對象的方法內，我們只應該調用一下範圍的方法
1）、該對象本身
2）、被當作方法的參數而傳遞進來的對象
3）、此方法所建立或執行個體化的任何對象
4）、對象的任何組件。
用代碼加以說明：

 1public float  getTemp()
 2{
 3    //  沒有採用該原則
 4    Thermoment thermoment = station.getThermoment();
 5    return thermoment.getTemperature();
 6}
 7
 8public float getTemp()
 9{
10    // 採用該原則
11    return station.getTemperature();
12}

（設計原則未完，待續）。

下一篇記錄“策略模式”。