記錄學習設計模式的過程

#單一職責原則

概念

• 定義：不要存在多於一個導致類變更的原因
• 一個類、介面、方法只負責一項職責
• 優點：、、

案例

單一職責原則很簡單，一個方法 一個類只負責一個職責，各個職責的程式改動，不影響其它程式。

這個比較容易理解，就舉個一個平常會碰到的情況。

package com.dsdj.design.principle.singleresponsibility;

/**
 * @ClassName TestService
 * @Description TODO
 * @Author dsdj
 * @Date 2018/10/9 下午9:36
 * @Version 1.0
 **/
 

public class TestService {

    public void getPrice(double price,String type){
        if ("肉類".equals(type)){
            System.out.println("價格是"+price);
        }
        if ("雞肉".equals(type)){
            System.out.println("價格是"+price);
        }
    }
}

這是定義的一個獲取價格的類。

package com.dsdj.design.
 
principle.singleresponsibility;

/**
 * @ClassName Test
 * @Description TODO
 * @Author dsdj
 * @Date 2018/10/11 下午8:16
 * @Version 1.0
 **/
public class Test {
    public static void main(String[] args) {
        TestService testService = new TestService();
        testService.getPrice(12,"肉類");
        testService.
 
getPrice(23.2,"雞肉");
    }
}

這是測試類

根據單一職責原則，我們進行如下的重構

將於雞肉有關的職責作為一個類

package com.dsdj.design.principle.singleresponsibility;

/**
 * @ClassName ChickenService
 * @Description TODO
 * @Author dsdj
 * @Date 2018/10/11 下午8:21
 * @Version 1.0
 **/
public class ChickenService {
    public void getPrice(double price){
        System.out.println("豬肉價格是"+price);
    }
}

將與肉類有關的職責作為一個類

package com.dsdj.design.principle.singleresponsibility;

/**
 * @ClassName PorkService
 * @Description TODO
 * @Author dsdj
 * @Date 2018/10/11 下午8:20
 * @Version 1.0
 **/
public class PorkService {
    public void getPrice(double price){
        System.out.println("豬肉價格是"+price);
    }
}

測試類在使用的時候就明確職責了

package com.dsdj.design.principle.singleresponsibility;

/**
 * @ClassName Test
 * @Description TODO
 * @Author dsdj
 * @Date 2018/10/11 下午8:16
 * @Version 1.0
 **/
public class Test {
    public static void main(String[] args) {
//        TestService testService = new TestService();
//        testService.getPrice(12,"肉類");
//        testService.getPrice(23.2,"雞肉");
        // 重構之後
        new ChickenService().getPrice(12.45);
        new PorkService().getPrice(34.2);

    }
}

介面隔離原則

概念

• 定義：用多個專門的介面，而不使用單一的總介面，客戶端不應該依賴他不需要的介面

• 一個類對一個類的依賴應該建立在最小的介面上

• 建立單一的幾口，不要建立龐大臃腫的介面

• 儘量細化介面，介面中的方法儘量少

• 適度原則，一定要適度

• 優點：高內聚，低耦合、可讀性

理解

客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。 這個原則很簡單，對於java等語言來說，B和D類依賴“介面I“（圖1），但是B並沒有使用方法4、5，D沒有使用方法2、3，但是因為依賴介面I，所以也需要定義並不使用的方法。 從前端角度來說，一個公共類它可能被不同的其它類引用，但是每個類只需要用到公共類的其中一個方法，但是卻需要把公共類全部引入，這樣就顯得太臃腫。

所以通過把一個大介面拆分成幾個小介面，可以使程式碼更精準，引用更靈活。

總結

• 單一職責原則是對類的約束
• 介面隔離原則是對抽象的約束
• 設計模式的使用要適度，不能過度使用，要結合實際的開發情況。