1.1 優化程式碼的第一步：單一職責原則

“這是一個備受爭議卻又極其重要的原則。只要你想和別人爭執、慪氣或者是吵架，這個原則是屢試不爽的”。因為單一職責的劃分界限並不總是那麼清晰，很多時候都是需要靠個人經驗來界定。當然，最大的問題就是對職責的定義，什麼是類的職責，以及怎麼劃分類的職責。

例子：圖片載入器(ImageLoader)

設計部分：必須考慮到可擴充套件性、靈活性 而檢測這一切是否符合需求的最好途徑就是開源,使用者不斷地提出需求、反饋問題。

1.2讓程式更穩定、更靈活:開閉原則

開閉原則是Java世界裡最基礎的設計原則，它指導我們如何建立一個穩定的、靈活的系統。開閉原則的定義是：軟體中的物件（類、模組、函式等）應該對於擴充套件是開放的，但是對於修改是封閉的。

在軟體開發過程中，最不會變化的就是變化本身。產品需要不斷升級、維護，沒有一個產品從第一個版本開發完就再沒有變化 了，除非下一個版本誕生之前它已經被終止。兒產品需要升級，修改原有程式碼可能引發其他問題，那麼如何確保原有軟體模組的正確性，以及儘量少地影響原有模組，答案就是開閉原則.

1.3 構建擴充套件性更好的系統：里氏替換原則

里氏替換原則英文全稱是Liskov Substitution Principle，縮寫是LSP。LSP的第一種定義是：如果對第一個型別為S的物件O1，都有型別為T的物件O2，使得以T定義的所有程式P在所有的物件O1都代換成O2時，程式P的行為沒有發生變化，那麼型別S是型別T的子型別。上面這種描述的確不太好理解，我們看看里氏替換原則的第二種定義：所有引用基類的地方必須能透明地使用其子類的物件。

我們都知道，面向物件的語言的三大特點是繼承、封裝、多型，里氏替換原則就是依賴於繼承、多型這兩大特性。里氏替換原則簡單來說，就是所有引用基類的地方必須能透明使用其子類的物件。通俗點講，只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或者異常，使用者可能不知道是父類還是子類。但是反過來就不行了，有子類出現的地方，父類未必就能適應。說了這麼多，其實最終總結就兩個字：抽象。

1.4讓專案擁有變化的能力:依賴倒置原則

依賴倒置原則英文全稱是Dependence Inversion Principle，縮寫是DIP。依賴倒置原則指代了一種特定的解耦形式，使得高層的模組不依賴於低層次的模組的實現細節的目的，依賴模組被顛覆了。怎麼理解呢？ 依賴倒置原則有以下幾個關鍵點： (1)高層模組不應該依賴低層次模組，兩者都應該依賴其抽象； (2)抽象不應該依賴細節； (3)細節應該依賴抽象； 在java語言中，抽象就是指介面或抽象類，兩者都是不能直接被例項化的；細節就是實現類，實現介面或繼承抽象類二產生的類就是細節，其特點就是，可以直接被例項化，也就是加上一個關鍵字new產生一個物件。高層模組就是呼叫端，底層模組就是具體實現類。依賴倒置原則在java語言中的表現就是：**模組間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面或抽象類產生的。**這又是一個將理論抽象化的例項，其實一句話就可以概括：面向介面程式設計，或者說面向抽象程式設計，這裡的抽象指的是介面或者抽象類。面向介面程式設計是面向物件的精髓之一，也就是上面強調的抽象。

如果類與類直接依賴於細節，那麼它們之間就有直接的耦合，當具體實現需要變化時，意味著要同時修改依賴者的程式碼，這限制 了系統的可擴充套件性。因此，要想讓系統變得更為靈活，抽象似乎成了我們唯一的手段。

1.5系統有更高的靈活性：介面隔離原則

介面隔離原則的英文全稱是InterfaceSegregation Principles，縮寫是ISP。ISP的定義是：客戶端不應該一類它不需要的介面。另一種定義是：類間的依賴關係應該建立在最小的介面上。介面隔離原則將非常龐大、臃腫的介面拆分成更小的和更具體的介面，這樣客戶將會只知道他們感興趣的方法。介面隔離原則的目的是系統解開耦合，從而容易重構、更改和重新部署。

介面隔離原則說白了就是,讓客戶端依賴的介面儘可能地小。Robert C Martin曾將 單一職責、開閉原則、里氏替換、介面隔離及依賴倒置（也稱依賴反轉）5個原則定義為SOLID原則，作為面向物件程式設計的5個基本原則。當這些原則被一起應用時，它們使得系統更加清晰、簡單，最大程度擁抱變化。

###1.6 更好的擴充套件性–迪米特原則

迪米特原則英文全稱是Law of Demeter,縮寫是LOD，也稱為最少知識原則(Least Knowledge Principle)雖然名字不同，但描述的是同一個原則：一個物件應該對其他物件有最少的瞭解。通俗地講，一個類應該對自己需要的耦合或呼叫的類知道得最少，類的內部如何實現與呼叫者或者依賴者沒關係，呼叫者或者依賴者只需要知道它需要的方法即可，其他的可一概不用管。類與類直接的關係越密切，耦合度也就越大，當一個類發生改變時，對另一個類的影響也越大。

迪米特原則還有一個英文解釋是Only talk to your immedate friends,翻譯過來就是：只與直接的朋友通訊。什麼叫直接的朋友呢？每個物件都必然會與其他物件有耦合關係，兩個物件之間的耦合就成為朋友，這種關係的型別有很多，如組合、聚合、依賴等。

總結

在實際的應用開發中，最難的不是完成應用的開發工作，而是在後續的升級、維護過程中讓應用系統能夠擁抱變化。擁抱變化也意味著在滿足需求且不破壞系統穩定性的前提下保持高可擴充套件性、高內聚、低耦合，在經歷了各版本的變更之後依然保持清晰、靈活、穩定的系統架構。當然，這是一個比較理想的情況，但我們必須要朝著這個方向去努力，這時遵循面向物件六大原則就是我們走向靈活軟體之路所邁出的第一步。