http://www.uml.org.cn/sjms/201211023.asp
http://blog.csdn.net/wangjunkg/article/details/3762132
http://blog.csdn.net/bboyfeiyu/article/details/50103471
一、單一職責原則：
就一個類而言，應該只專注於做一件事和僅有一個引起它變化的原因。一個類只負責一項職責。一個類中應該是一組相關性很高的函數、數據的封裝。 所謂職責，我們可以理解他爲功能，就是設計的這個類功能應該只有一個。因爲職責是變化的一個軸線，當需求變化時，該變化會反映類的職責的變化。 使用SRP注意點：
1.可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
2.提高類的可讀性，提高系統的可維護性；
3.變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。
4.在代碼可控時，各個模塊、類、方法...都應該遵循單一職責原則。
二、開閉原則
開放－封閉原則 說明：軟件中的對象（類、模塊、函數等）應該對於擴展是開放的，但是，對於修改是封閉的。
按照OCP原則設計出來的系統，降低了程序各部分之間的耦合性，其適應性、靈活性、穩定性都比較好。當已有軟件系統需要增加新的功能時，不需要對作爲系統基礎的抽象層進行修改，只需要在原有基礎上附加新的模塊就能實現所需要添加的功能。增加的新模塊對原有的模塊完全沒有影響或影響很小，這樣就無須爲原有模塊進行重新測試。 在面向對象設計中，不允許更改的是系統的抽象層，而允許擴展的是系統的實現層。換言之，定義一個一勞永逸的抽象設計層，允許儘可能多的行爲在實現層被實現。對一個事物抽象化，實質上是在概括歸納總結它的本質。抽象讓我們抓住最最重要的東西，從更高一層去思考。這降低了思考的複雜度，我們不用同時考慮那麼多的東西。換言之，我們封裝了事物的本質，看不到任何細節。 在面向對象編程中，通過抽象類及接口，規定了具體類的特徵作爲抽象層，相對穩定，不需更改，從而滿足“對修改關閉”；而從抽象類導出的具體類可以改變系統的行爲，從而滿足“對擴展開放”。 對實體進行擴展時，不必改動軟件的源代碼或者二進制代碼。
三、里氏代換原則
當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，儘量不要重寫父類A實現好的方法，也儘量不要重載父類A的方法。子類可以擴展父類的功能，但不能改變父類原有的功能。
說明：子類型必須能夠替換它們的基類型。一個軟件實體如果使用的是一個基類，那麼當把這個基類替換成繼承該基類的子類，程序的行爲不會發生任何變化。軟件實體察覺不出基類對象和子類對象的區別。
優點：可以很容易的實現同一父類下各個子類的互換，而客戶端可以毫不察覺。
1.子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2.子類中可以增加自己特有的方法。
3.當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
4.當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
四、依賴倒置原則
抽象不應當依賴於細節；細節應當依賴於抽象；要針對接口編程，不針對實現編程。高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。傳遞依賴關係:接口傳遞、造方法傳遞和setter方法傳遞.面向接口編程.低層模塊儘量都要有抽象類或接口，或者兩者都有。變量的聲明類型儘量是抽象類或接口。使用繼承時遵循里氏替換原則。
五、接口隔離原則
使用多個專一功能的接口比使用一個的總接口總要好。將非常龐大、臃腫的接口拆分成爲更小的和更具體的接口.單一職責原則主要是約束類，其次纔是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序整體框架的構建。單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴的隔離.
六、迪米特法則
對象與對象之間應該使用儘可能少的方法來關聯，避免千絲萬縷的關係。只與直接的朋友通信。在類的劃分上，應當創建有弱耦合的類。類之間的耦合越弱，就越有利於複用。在類的結構設計上，每一個類都應當儘量降低成員的訪問權限。一個類不應當public自己的屬性，而應當提供取值和賦值的方法讓外界間接訪問自己的屬性。
http://blog.csdn.net/wangjunkg/article/details/3762132
http://blog.csdn.net/bboyfeiyu/article/details/50103471
一、單一職責原則：
就一個類而言，應該只專注於做一件事和僅有一個引起它變化的原因。一個類只負責一項職責。一個類中應該是一組相關性很高的函數、數據的封裝。 所謂職責，我們可以理解他爲功能，就是設計的這個類功能應該只有一個。因爲職責是變化的一個軸線，當需求變化時，該變化會反映類的職責的變化。 使用SRP注意點：
1.可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
2.提高類的可讀性，提高系統的可維護性；
3.變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。
4.在代碼可控時，各個模塊、類、方法...都應該遵循單一職責原則。
二、開閉原則
開放－封閉原則 說明：軟件中的對象（類、模塊、函數等）應該對於擴展是開放的，但是，對於修改是封閉的。
按照OCP原則設計出來的系統，降低了程序各部分之間的耦合性，其適應性、靈活性、穩定性都比較好。當已有軟件系統需要增加新的功能時，不需要對作爲系統基礎的抽象層進行修改，只需要在原有基礎上附加新的模塊就能實現所需要添加的功能。增加的新模塊對原有的模塊完全沒有影響或影響很小，這樣就無須爲原有模塊進行重新測試。 在面向對象設計中，不允許更改的是系統的抽象層，而允許擴展的是系統的實現層。換言之，定義一個一勞永逸的抽象設計層，允許儘可能多的行爲在實現層被實現。對一個事物抽象化，實質上是在概括歸納總結它的本質。抽象讓我們抓住最最重要的東西，從更高一層去思考。這降低了思考的複雜度，我們不用同時考慮那麼多的東西。換言之，我們封裝了事物的本質，看不到任何細節。 在面向對象編程中，通過抽象類及接口，規定了具體類的特徵作爲抽象層，相對穩定，不需更改，從而滿足“對修改關閉”；而從抽象類導出的具體類可以改變系統的行爲，從而滿足“對擴展開放”。 對實體進行擴展時，不必改動軟件的源代碼或者二進制代碼。
三、里氏代換原則
當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，儘量不要重寫父類A實現好的方法，也儘量不要重載父類A的方法。子類可以擴展父類的功能，但不能改變父類原有的功能。
說明：子類型必須能夠替換它們的基類型。一個軟件實體如果使用的是一個基類，那麼當把這個基類替換成繼承該基類的子類，程序的行爲不會發生任何變化。軟件實體察覺不出基類對象和子類對象的區別。
優點：可以很容易的實現同一父類下各個子類的互換，而客戶端可以毫不察覺。
1.子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2.子類中可以增加自己特有的方法。
3.當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
4.當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
四、依賴倒置原則
抽象不應當依賴於細節；細節應當依賴於抽象；要針對接口編程，不針對實現編程。高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。傳遞依賴關係:接口傳遞、造方法傳遞和setter方法傳遞.面向接口編程.低層模塊儘量都要有抽象類或接口，或者兩者都有。變量的聲明類型儘量是抽象類或接口。使用繼承時遵循里氏替換原則。
五、接口隔離原則
使用多個專一功能的接口比使用一個的總接口總要好。將非常龐大、臃腫的接口拆分成爲更小的和更具體的接口.單一職責原則主要是約束類，其次纔是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序整體框架的構建。單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴的隔離.
六、迪米特法則
對象與對象之間應該使用儘可能少的方法來關聯，避免千絲萬縷的關係。只與直接的朋友通信。在類的劃分上，應當創建有弱耦合的類。類之間的耦合越弱，就越有利於複用。在類的結構設計上，每一個類都應當儘量降低成員的訪問權限。一個類不應當public自己的屬性，而應當提供取值和賦值的方法讓外界間接訪問自己的屬性。
