1--單一職責原則
顧名思義 一個類只承擔一個功能，這樣可以減少功能耦合，
仔細想想，如果一個類承擔了多個功能，當某個功能發生變化，可能會導致類的其他功能受影響，單一職責原則使得各功能之間互不影響，降低開發過程中出現不必要的風險
2--里氏替換原則
子類可以拓展父類功能，但是不能修改父類原有的功能
子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
（加上個人理解補充：父類儘量寫抽象方法，讓子類去具體實現，這樣會更加靈活，提高代碼的重用性）
3--依賴倒置原則
定義：
1.高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象
2.細節應該依賴抽象，而抽象不應該依賴細節
如下面例子，有一個需求，要定義功能不同的打印機，都有打印功能，但顏色等細節功能是不同的，一般的方法是這樣定義的
Public class 打印機（）{
Public void 打印（）{}
}
Public cliass 黑色打印機 extends 打印機（）{
Public vlid 打印（）{打印黑色}
}
Public cliass 彩色色打印機 extends 打印機（）{
Public vlid 打印（）{打印彩色}
}
最後Main方法中根據不同需求掉用不同顏色打印機的打印方法，
If（需要黑色）{
New 黑色打印機（）. 打印黑色（）；
}
If（需要的是彩色）{
New 彩色打印機（）. 打印彩色（）；
}......
當打印機的顏色增多時，就意味着要實例化大量的不同類對象，這樣會很不方便
採用下面的方式會發現有很大的優點
各種顏色打印機依賴於接口（抽象）而不是依賴於顏色（細節）
public interface Box {//抽象接口
public abstract void doPrint();
}
public class BlackCartridge implements Box{//黑色打印機實現接口
public void doPrint (){
System.out.println("黑色墨盒執行噴墨打印");
}
}
public class ColorCartridge implements Box{//彩色打印機實現接口
public void doPrint (){
System.out.println("彩色墨盒執行噴墨打印");
}
}
public class Printer {//中間轉化類，這個很重要（通過他來調用具體打印機）
public void print(Box box){
box.doPrint ();
}
}
public class PrinterStart {
public static void main(String[] args) {
Printer printer= new Printer();
printer.print(new BlackCartridge());
}
}
於是乎就發現原來實現不同的打印機，需要實例化不同的類，現在通過printer 這一中間類可以通過傳入不同的打印機參數就可以實現不同的打印機顏色需求了。
4--接口隔離原則
接口隔離原則（Interface Segregation Principle ISP）：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上
定義：
1.使用多個專門的接口比使用單一的總接口要好
2.一個類對另外一個類的依賴性應當是建立在最小的接口上的
3.一個接口代表一個角色，不應當將不同的角色都交給一個接口。沒有關係的接口合併在一起，形成一個臃腫的大接口，這是對角色和接口的污染
4.不應該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構
問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對於類A和類B來說不是最小接口，則類B和類D必須去實現他們不需要的方法。
解決方案：將大接口I拆分爲獨立的幾個小接口，類A和類C分別與他們需要的接口建立依賴關係。
5--開閉原則
開閉原則（Open Closed Principle OCP）：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉，此原則爲設計模式的總綱。
定義：
1.對於擴展是開放的（Open for extension）。這意味着模塊的行爲是可以擴展的。當應用的需求改變時，我們可以對模塊進行擴展，使其具有滿足那些改變的新行爲。
2.對於修改是關閉的（Closed for modification）。對模塊行爲進行擴展時，不必改動模塊的源代碼或者二進制代碼。
問題由來：在軟件的生命週期內，因爲變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。
開閉原則的重要性：
開閉原則對測試的影響（開閉原則可是保持原有的測試代碼仍然能夠正常運行，我們只需要對擴展的代碼進行測試就可以了）
開閉原則可以提高複用性（在面向對象的設計中，所有的邏輯都是從原子邏輯組合而來的，而不是在一個類中獨立實現一個業務邏輯。只有這樣代碼纔可以複用，粒度越小，被複用的可能性就越大）
開閉原則可以提高可維護性
面向對象開發的要求
實現方法：
實現開閉原則的關鍵就在於“抽象”。把系統的所有可能的行爲抽象成一個抽象底層，這個抽象底層規定出所有的具體實現必須提供的方法的特徵。作爲系統設計的抽象層，要預見所有可能的擴展，從而使得在任何擴展情況下，系統的抽象底層不需修改；同時，由於可以從抽象底層導出一個或多個新的具體實現，可以改變系統的行爲，因此系統設計對擴展是開放的。
關於系統可變的部分，還有一個更具體的對可變性封裝原則（Principle of Encapsulation of Variation, EVP），它從軟件工程實現的角度對開閉原則進行了進一步的解釋。EVP要求在做系統設計的時候，對系統所有可能發生變化的部分進行評估和分類，每一個可變的因素都單獨進行封裝。
我們在實際開發過程的設計開始階段，就要羅列出來系統所有可能的行爲，並把這些行爲加入到抽象底層，根本就是不可能的，這麼去做也是不經濟的。因此我們應該現實的接受修改擁抱變化，使我們的代碼可以對擴展開放，對修改關閉。
666導航網 可以自由收藏管理個人常用網址的便捷上網工具
