Java設計模式-設計模式的六種原則

六種設計原則

單一職責原則

不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。 

問題由來：類T負責兩個不同的職責：職責P1，職責P2。當因職責P1需求改變而需要修改類別T時，有可能會導致原本運作正常的職責P2功能發生故障。

一句話總結：不能為圖代碼量少，把牛頭馬嘴一起往一個類塞

里氏替換原則

1.子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。

2.子類別中可以增加自己特有的方法。

3.當子類別的方法重載父類別的方法時，方法的前置條件（即方法的形參）要比父類別方法的輸入參數更寬鬆。

4.當子類別的方法實作父類別的抽象方法時，方法的後置條件（即方法的回傳值）比父類別更嚴格。

一句話總結：盡量不要重寫父類的已經實現了的方法，可以用接口等其他方法繞過

依賴倒置原則

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

這裡用一個列子來說明：

import java.util.LinkedList;  
import java.util.Queue;  
  
  
  
interface IEAT  
{  
    public void eat();//抽象吃这个动作  
}  
class EatApple implements IEAT  
{  
  
    @Override  
    public void eat()   
    {  
        //这里是吃苹果  
        System.out.print("eat a apple");  
          
    }  
}  
class EatWater implements IEAT  
{  
  
    @Override  
    public void eat() {  
        // 这里是吃水  
        System.out.print("dringk water");  
          
    }  
      
}  
public class Human  
{  
    public void dosomething(IEAT ieat)//我爱吃东西，吃什么呢，看传入什么  
    {  
        ieat.eat();  
    }  
    /* 
    public void dosomething(String food)//我爱吃东西，吃什么呢，看传入什么 
    { 
        if(food.equals("apple")) 
        { 
            //吃苹果 
        } 
        if(food.equals("water")) 
        { 
            //喝水 
        } 
    } 
    */  
    public static void main(String[] args)  
    {  
        Human human=new Human();  
        /* 
        human.dosomething("apple"); 
        human.dosomething("water"); 
         */  
        //给你吃个苹果  
        human.dosomething(new EatApple());  
        //再给你喝点水  
        human.dosomething(new EatWater());  
    }  
}

其中註解的就是我們常用的方法。這個方法非常不適擴展，因為如果要吃香蕉，吃西瓜，又要在dosomething裡面寫一堆判斷。寫著寫著就混了。

因此一句話總結：多用抽象的介面來描述相同的動作，降低實現這個動作的人和物之間的耦合度

介面隔離原則

客戶端不應該依賴它不需要的介面；一個類別對另一個類別的依賴應該建立在最小的介面上。

問題由來：類A透過接口I依賴類B，類C透過接口I依賴類D，如果接口I對於類A和類B來說不是最小接口，則類B和類D必須去實現他們不需要的方法。

一句話總結：就好比魚和人兩個類，魚是游泳和腮呼吸兩個動作，人是走路和吃飯兩個動作，這些動作不能寫在一個接口裡面，把這四個動作都包含了。要拆成專門對魚和人的兩個介面才行。

迪米特法則

迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類別來說，無論邏輯多麼複雜，都盡量地的將邏輯封裝在類別的內部，對外除了提供的public方法，不對外洩漏任何資訊。

這個有點不好記，總結就是：father1

開閉原則

這個沒啥已有好說的：盡量透過修改軟體實體的行為來實現變化，而不是透過修改擴充的程式碼來實現變化。