物件導向五大基本原則

一、單一職責原則

一個類應該僅有一個引起它變化的原因(最簡單，最容易理解卻最不容易做到的一個設計原則)

職員類例子：比如在職員類裡，將工程師、銷售人員、銷售經理這些情況都放在職員類裡考慮，其結果將會非常混亂，在這個假設下，職員類裡的每個方法都要if else判斷是哪種情況，從類結構上來說將會十分臃腫，並且上述三種的職員型別，不論哪一種發生需求變化，都會改變職員類！這個是大家所不願意看到的！

二、開放封閉原則

        一個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉。模組應儘量在不修改原（是“原”，指原來的程式碼）程式碼的情況下進行擴充套件。通過介面或者抽象類約束擴充套件

//未實現開放封閉

public class BankProcess
    {  //存款 
       public void Deposite(){}
        //取款
        public void Withdraw(){ }
        //轉賬
        public void Transfer(){}
    }

//實現了開放封閉

public  interface IBankProcess{  void Process();}
public class DepositProcess : IBankProcess
    {
        public void Process()
        { //辦理存款業務
           Console.WriteLine("Process Deposit");
        }
}

public class WithDrawProcess : IBankProcess

    {
        public void Process()
       { //辦理取款業務
            Console.WriteLine("Process WithDraw");
        }
}
public class TransferProcess : IBankProcess
    {
        public void Process()
        { //辦理轉賬業務
         Console.WriteLine("Process Transfer");
        }
    }

這樣以後在增加某個業務的時候，只需要擴充套件相應的類就可以了，不需要修改程式碼

三、裡式代換原則

  派生類(子類)物件能夠替換其基類(父類)物件被呼叫

       里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規範。

     

四、依賴倒轉原則

   面向介面程式設計。

   三句話：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

場景是這樣的，母親給孩子講故事，只要給她一本書，她就可以照著書給孩子講故事了。程式碼如下：

class Book{
    public String getContent(){
        return "很久很久以前有一個阿拉伯的故事……";
    }
}
class Mother{
    public void narrate(Book book){
        System.out.println("媽媽開始講故事");
        System.out.println(book.getContent());
    }
}
public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
    }
}

假如有一天，需求變成這樣：不是給書而是給一份報紙，讓這位母親講一下報紙上的故事，報紙的程式碼如下：

class Newspaper{
    public String getContent(){
        return "林書豪38+7領導尼克斯擊敗湖人……";
    }
}

這位母親卻辦不到，因為她居然不會讀報紙上的故事，這太荒唐了，只是將書換成報紙，居然必須要修改Mother才能讀。假如以後需求換成雜誌呢？換成網頁呢？還要不斷地修改Mother，這顯然不是好的設計。原因就是Mother與Book之間的耦合性太高了，必須降低他們之間的耦合度才行。

我們引入一個抽象的介面IReader。讀物，只要是帶字的都屬於讀物：

interface IReader{
    public String getContent();
}

class Newspaper implements IReader {
    public String getContent(){
        return "林書豪17+9助尼克斯擊敗老鷹……";
    }
}
class Book implements IReader{
    public String getContent(){
        return "很久很久以前有一個阿拉伯的故事……";
    }
}
 
class Mother{
    public void narrate(IReader reader){
        System.out.println("媽媽開始講故事");
        System.out.println(reader.getContent());
    }
}
 
public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
        mother.narrate(new Newspaper());
    }
}

這樣修改後，無論以後怎樣擴充套件Client類，都不需要再修改Mother類了。這只是一個簡單的例子，實際情況中，代表高層模組的Mother類將負責完成主要的業務邏輯，一旦需要對它進行修改，引入錯誤的風險極大。所以遵循依賴倒置原則可以降低類之間的耦合性，提高系統的穩定性，降低修改程式造成的風險。

採用依賴倒置原則給多人並行開發帶來了極大的便利，比如上例中，原本Mother類與Book類直接耦合時，Mother類必須等Book類編碼完成後才可以進行編碼，因為Mother類依賴於Book類。修改後的程式則可以同時開工，互不影響，因為Mother與Book類一點關係也沒有。參與協作開發的人越多、專案越龐大，採用依賴導致原則的意義就越重大。現在很流行的TDD開發模式就是依賴倒置原則最成功的應用。

五、介面隔離原則

  這個原則的意思是：使用多個專門的介面比使用單個介面要好的多！