關于面向對象編程的一些理解，這本書主要看六大原則的部分，書中關于設計模式的內容由于之前的那本《設計模式與游戲完美開發》已經很好的講解了游戲開發領域的應用，所以不多關注。

面向對象的六大原則

單一職責原則SRP：一個類應該只有一個發生變化的原因，如果你能夠想到多余一個的動機去改變一個類，那么這個類就具有多于一個的職責。

public interface Modem {// 連接管理public void Dial(string pno);public void Hangup();// 數據通信public void Send(char c);public char Recv(); }

上述代碼一個調制解調器所具有的功能，在接口中顯示出連接管理和數據通信兩個職責。但這目前還不是需要分離職責的理由，如果應用程序的變化會影響對方，那么是應該被分離的；反之變化總是導致兩個職責同時變化，那實際上是不必分離的。

public interface DataChannel {// 數據通信public void Send(char c);public char Recv(); } public interface Connection {// 連接管理public void Dial(string pno);public void Hangup(); } public class ModemImplementation { }

盡管ModemImplementation類會混雜DataChannel和Connection，這并不是我們希望的，但對于其他部分來說，通過接口分離我們已經解耦了概念，而這個類除了Main需要知道，誰也不需要知道它的存在。

開閉原則OCP：軟件實體（類、模塊、函數等）應該是可以拓展的，但是不可修改。如果正確的應用OCP，那么在進行改動時，只需要添加新的代碼，而不是改動已有的代碼。
拓展和修改看似是沖突的，如何在不改動模塊代碼的情況下更改它的行為呢？答案就是抽象。由于模塊依賴于一個固定的抽象體，所以它對于更改可以是封閉的。同時，通過從這個抽象體派生，可以拓展次模塊的行為。遵循OCP的開發過程是困難的，我們很難保證能夠預測到變化的發生，如果我們決定接受重構，那么重構的時間來的越早對項目是越有利的。

里氏替換原則LSP，子類必須能夠替換掉他們的基類

public class Shape {public static void DrawShape(Shape s) {if (s.type == ShapeType.square)(s as Square).Draw();else if (s.type == ShapeType.circle)(s as Circle).Draw();} } public class Circle: Shape{} public class Square: Shape{}

上述代碼典型的違反了OCP，它必須知道Shape類每個可能的派生類，并且每次創建一個從Shape類派生的新類時都必須要更改它。但是從本質上看，開發者采用重寫Draw()的方式，以致于子類無法替換Shape()，違反了LSP，這個違法又迫使DrawShape()違反了OCP。LSP是使得OCP成為可能的主要原則之一，正事子類型的可替換性才使得使用基類型表示的模塊在無需修改的情況下就可以拓展。

依賴倒置原則DIP：高層次模塊不應該依賴于低層次模塊，二者都應該依賴于抽象；抽象不應該依賴于細節，細節應該依賴于抽象。

上述啟發規則對于某些穩定的類是不太合理的，有些類直接依賴于它也不會造成損害，比如String。然而開發者編寫的大多數具體類都是不穩定的，為了不直接依賴于這些不穩定的具體類，通過隱藏到抽象接口的后面，以隔離它們的不穩定性。

public class Button {private Lamp lamp;public void Poll() {if (/*some condition*/)lamp.TurnOn();} }

上述代碼Button類直接依賴于Lamp類，當Lamp類發生改變時，Button類會受到影響，這個方案違反了DIP，高層策略沒有和低層分離。在這個例子中，背后的抽象是檢測用戶的開/關指令傳給目標對象。至于用什么機制檢測，目標對象是什么，都無關緊要。

public interface ButtonServer {public virtual void TurnOff();public virtual void TurnOn(); } public class Lamp : ButtonServer { } public class Button {private ButtonServer bs;public void Poll() {if (/*some condition*/)bs.TurnOn();} }

上述代碼就很好的倒置了依賴的方向，Lamp依賴于其他類而不是被其他類依賴，知道如何操縱ButtonServer接口的對象都能夠控制Lamp。對于面向過程程序設計所創建出來的依賴關系結構，策略依賴于細節，這是糟糕的，這樣策略會受到細節改變的影響。DIP是面向對象設計的標志所在，如果依賴關系不是倒置的，它就是過程化的設計。

接口隔離原則ISP：類與類之間的依賴關系應該建立在最小的接口之上，不應該強迫類依賴并未使用的方法。如果一個客戶程序依賴于那些它們不使用的方法，那么這些客戶程序就面臨著由于這些未使用方法的改變所帶來的變更。

迪米特原則LoD：也稱為最少知識原則，一個對象應當對其他對象有最少的了解

public class Computer{public void SaveCurrentTask(){ }public void CloseService(){ }public void CloseScreen(){ }public void ClosePower(){ } } public class Person{private Computer c;public void ClickCloseButton(){ c.SaveCurrentTask();c.CloseService();c.CloseScreen();c.ClosePower();} }

上述代碼展示了Person想要通過點擊按鈕關閉Computer的情況，可是由于Computer所有方法都是公開的，Person并不知道電腦關閉的流程，只有Person對Computer關機的流程全部熟悉才能正確的寫出ClickCloseButton()這個方法，這違背了LoD。

public class Computer{private void SaveCurrentTask(){ }private void CloseService(){ }private void CloseScreen(){ }private void ClosePower(){ }private void Close(){SaveCurrentTask();CloseService();CloseScreen();ClosePower();} } public class Person{private Computer c;public void ClickCloseButton(){c.Close();} }

改進是明顯的，現在Person不需要了解任何Computer的內部邏輯就可以寫出ClickCloseButton()方法了。

---

小結：細心的讀者會發現最后一個例子，也是明顯的違背DIP，具體類Person依賴于具體類Computer，我們可以想象如果Person還想要通過點擊按鈕關閉電視、空調等其他機器的時候。但是如果明確了這個項目只需要Person控制電腦，絕不可能出現其他設備呢？難道我們還要再抽象出一個mechine類嗎？拒絕不成熟的抽象和抽象本身一樣重要。

總結

以上是生活随笔為你收集整理的[读书笔记] 敏捷软件开发：原则、模式与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。