設計模式--6大原則--單一職責原則

單一職責原則（Single Responsibility Principle），簡稱SRP。

定義：

There should never be more than one reason for a class to change.

應該有且僅有一個緣由引發類的變動。

 

有時候，開發人員設計接口的時候會有些問題，好比用戶的屬性和用戶的行爲被放在一個接口中聲明。這就形成了業務對象和業務邏輯被放在了一塊兒，這樣就形成了這個接口有兩種職責，接口職責不明確，按照SRP的定義就違背了接口的單一職責原則了。

下面是個例子：

package com.loulijun.chapter1;

 

public interface Itutu {

    //身高

    void setShengao(double height);

    double getShengao();

    //體重

    void setTizhong(double weight);

    double getTizhong();

    //吃飯

    boolean chiFan(boolean hungry);

    //上網

    boolean shangWang(boolean silly);

}

　　上面的例子就存在這個問題，身高、體重屬於業務對象，與之相應的方法主要負責用戶的屬性。而吃飯、上網是相應的業務邏輯，主要負責用戶的行爲。可是這就會給人一種不知道這個接口究竟是作什麼的感受，職責不清晰，後期維護的時候也會形成各類各樣的問題。

解決辦法：單一職責原則，將這個接口分解成兩個職責不一樣的接口便可

ItutuBO.java：負責tutu（塗塗，假如是我的名）的屬性

package com.loulijun.chapter1;

 

/**

 * BO：Bussiness Object，業務對象

 * 負責用戶的屬性

 * @author Administrator

 *

 */

public interface ItutuBO {

    //身高

    void setShengao(double height);

    double getShengao();

    //體重

    void setTizhong(double weight);

    double getTizhong();

}

ItutuBL.java：負責塗塗的行爲

package com.loulijun.chapter1;

/**

 * BL:Business Logic,業務邏輯

 * 負責用戶的行爲

 * @author Administrator

 *

 */

public interface ItutuBL {

    //吃飯

    boolean chiFan(boolean hungry);

    //上網

    boolean shangWang(boolean silly);

}

這樣就實現了接口的單一職責。那麼實現接口的時候，就須要有兩個不一樣的類

TutuBO.java

package com.loulijun.chapter1;

 

public class TutuBO implements ItutuBO {

    private double height;

    private double weight;

    @Override

    public double getShengao() {        

        return height;

    }

 

    @Override

    public double getTizhong() {

        return weight;

    }

 

    @Override

    public void setShengao(double height) {

        this.height = height;

    }

 

    @Override

    public void setTizhong(double weight) {

        this.weight = weight;

    }

 

}

TutuBL.java

package com.loulijun.chapter1;

 

public class TutuBL implements ItutuBL {

 

    @Override

    public boolean chiFan(boolean hungry) {

        if(hungry)

        {

            System.out.println("去吃火鍋...");

            return true;

        }

        return false;

    }

 

    @Override

    public boolean shangWang(boolean silly) {

        if(silly)

        {

            System.out.println("好無聊啊，上會網...");

            return true;

        }

        return false;

    }

 

}

這樣就清晰了，當須要修改用戶屬性的時候只須要對ItutuBO這個接口來修改，只會影響到TutuBO這個類，不會影響其餘類。

那麼單一職責原則的意義何在呢？

一、下降類的複雜性，實現什麼樣的職責都有清晰的定義

二、提升可讀性

三、提升可維護性

四、下降變動引發的風險，對系統擴展性和維護性頗有幫助

 

可是、使用單一職責原則有一個問題，「職責」沒有一個明確的劃分標準，若是把職責劃分的太細的話會致使接口和實現類的數量劇增，反而提升了複雜度，下降了代碼的可維護性。因此使用這個職責的時候還要具體狀況具體分析。建議就是接口必定要採用單一職責原則，實現類的設計上儘量作到單一職責原則，最好是一個緣由引發一個類的變化。