【IT168 評論】
一、單一職責原則
Single Responsibility Principle，應該有且僅有一個原因引起類的變更，實際中比較不好把握，因為職責的劃分沒有一個統一的標準。
二、裡氏替換原則
Liskov Substitution Principle，通俗點講，只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是，反過來就不行了，有子類出現的地方，父類未必就能適應。
三、依賴倒置原則
Dependence Inversion Principle，高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象;在Java語言中的表達就是，模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過接口或抽象類產生的;接口或抽象類不依賴於實現類;實現類依賴接口或抽象類。
四、接口隔離原則
Interface Segregation Principle，建立單一接口，不要建立臃腫龐大的接口，接口儘量細化，同時接口中的方法儘量少。(單一職責要求的是類和接口職責單一，注重的是職責，這是業務邏輯上的劃分，而接口隔離原則要求接口的方法儘量少。例如一個接口的職責可能包含10個方法，這10個方法都放在一個接口中，並且提供給多個模塊訪問，各個模塊按照規定的權限來訪問，在系統外通過文檔約束「不使用的方法不要訪問」，按照單一職責原則是允許的，按照接口隔離原則是不允許的，因為它要求「儘量使用多個專門的接口」。)
五、迪米特原則
Law of Demeter，一個對象應該對其他對象有最少的了解。通俗地講，一個類應該對自己需要耦合或調用的類知道得最少，你(被耦合或調用的類)的內部是如何複雜都和我沒關係，那是你的事情，我就知道你提供的這麼多public方法，我就調用這麼多，其他的我一概不關心。
六、開閉原則
Open Closed Principle，軟體實體應該對擴展開放，對修改關閉，其含義是說一個軟體實體應該通過擴展來實現變化，而不是通過修改已有的代碼來實現變化。
總結：
之所以有這麼多的原則來指導我們進行程序的設計和開發，是因為我們的程序存在未知的改變。為了以最低的代價擁抱這種未知的變化，前輩們給我們總結了這麼多原則，開閉原則應該是每一個大師的終極目標。在所有這些原則中，很重要的一環就是抽象類和接口的靈活運用。後面的23種具體的設計模式也是對「變化「的總結。