單一職責原則

時間 2019-11-24

標籤單一職責原則欄目設計模式简体版

原文原文鏈接

我的博客原文：單一職責原則java

設計模式六大原則之一：單一職責原則git

簡介

姓名：單一職責原則github

英文名 ：Single Responsibility Principle設計模式

座右銘 ：There should never be more than one reason for a class to change. 應當有且僅有一個緣由引發類的變動。。。意思就是無論幹啥，我都只幹一件事，你叫我去買菜，我就只買菜，叫我順便去倒垃圾就不幹了，就這麼拽ide

脾氣：一個字「拽」，兩個字「特拽「spa

伴侶：老子職責單一，哪來的伴侶？設計

我的介紹 ：在這我的兼多責的社會裏，我顯得那麼的特立獨行，卻不知，如今社會上發生的不少事情都是由於沒有處理好職責致使的，好比，常常有些父母帶着小孩，一邊玩手機，致使小孩弄丟、發生事故等等code

單一職責應用範圍

單一職責原則適用的範圍有接口、方法、類。按你們的說法，接口和方法必須保證單一職責，類就沒必要保證，只要符合業務就行。cdn

方法

設想一下這個場景：假設咱們要作一個用戶修更名字以及修改密碼的功能，能夠有多種實現方案，好比下面列舉 2 種實現方式blog

代碼：SrpOfMethod.java

第一種實現方式

/** * 錯誤的示範 */
enum OprType {
    /** * 更新密碼 */
    UPDATE_PASSWORD,
    /** * 更新名字 */
    UPDATE_NAME;
}

interface UserOpr {
    boolean updateUserInfo(User user, OprType oprType);
}

class UserOprImpl implements UserOpr {

    @Override
    public boolean updateUserInfo(User user, OprType oprType) {
        if (oprType == OprType.UPDATE_NAME) {
            // update name
        } else if (oprType == OprType.UPDATE_PASSWORD) {
            // update password
        }
        return true;
    }
}
複製代碼

第二種實現方式

/** * 正確的示範 */
interface UserOpr2 {
    boolean updatePassword(User user, String password);
    boolean updateUserInfo(User user);
}

class UserOprImpl2 implements UserOpr2 {

    @Override
    public boolean updatePassword(User user, String password) {
        user.setPassword(password);
        // update password
        return true;
    }

    @Override
    public boolean updateUserInfo(User user) {
        // update user info
        return true;
    }
}
複製代碼

2 種實現有什麼區別呢？第一種實現經過 OprType 類型的不一樣來作不一樣的事情，把修改密碼和修更名字耦合在一塊兒，容易引發問題，只要稍不注意，傳錯枚舉值就悲劇了，在代碼中也無法很直接看到是作什麼操做，也就是這個方法的職責不明確。而第二種實現，把修改密碼和修更名字分離開來，也就是把修改密碼和修更名字都當作獨自的職責處理，這樣子就很清晰明瞭，你調用哪一個方法，就很明確的知道這個方法是實現什麼邏輯。結論是啥呢？用第二種方式實習才符合單一職責原則。現實中看到不少像第一種實現的代碼，並且是枚舉有十來個的狀況，看代碼真費勁。

接口

設想一下這個場景，假設咱們讓小明去倒垃圾，小紅去買菜，小紅回來後再叫小紅去洗碗。下面也舉 2 個實現的例子。

代碼：SrpOfInterface.java

第一種實現方式

/** * 錯誤的示範 */
interface Housework {
    void shopping();
    void pourGarbage();
}

class XiaoMing implements Housework {

    @Override
    public void shopping() {
        // 不購物
    }

    @Override
    public void pourGarbage() {
        System.out.println("pourGarbage ...");
    }
}

class XiaoHong implements Housework {

    @Override
    public void shopping() {
        System.out.println("shopping ...");
    }

    @Override
    public void pourGarbage() {
        // 從不倒垃圾
    }
}
複製代碼

中途回來小紅去洗碗，要怎麼實現？按這個寫法，就在 Housework 接口添加 washingUp() 方法，而後小明和小紅依次都實現洗碗這個方法，只是小明不作具體實現代碼，這樣子是否是以爲很彆扭，不符合單一職責原則的，修改一個地方，不影響其餘不須要改變的地方，只對須要用到的地方作修改。小明原本就不用洗碗，卻要去實現洗碗這個方法。

第二種實現方式

/** * 正確的示範 */
interface Shopping {
    void doShopping();
}

interface PourGarbage {
    void doPourGarbage();
}

interface WashingUp {
    void doWashingUp();
}

class XiaoMing2 implements PourGarbage {

    @Override
    public void doPourGarbage() {
        System.out.println("pourGarbage ...");
    }
}

class XiaoHong2 implements Shopping, WashingUp {

    @Override
    public void doShopping() {
        System.out.println("shopping ...");
    }

    @Override
    public void doWashingUp() {
        System.out.println("washing up ...");
    }
}
複製代碼

能夠看到，這種實現把不一樣的家務都當作不一樣的職責，分離開來，這種實現能夠按需實現作家務的類型，小明只須要去倒垃圾，就實現 PourGarbage 接口，小紅去購物和洗碗，就實現 Shopping 和 WashingUp 接口，徹底不會影響到對方，這纔是完美的根據單一職責原則編寫出來的代碼。

類

類這個看了一些資料都說無法硬性要求必定按單一職責原則分，或者說類的職責可大可小，沒有很明確的像上面接口那樣按照單一職責原則分就很清晰也頗有道理。設想一下這個場景：咱們要實現一個用戶註冊、登陸、註銷操做，能夠像以下 2 種實現方式

代碼：SrpOfClass.java

第一種實現方式

從用戶的角度考慮，這些操做都是用戶的行爲，能夠放在一個統一的類 UserBiz

class UserBiz {

    public boolean register(User user){
        // 註冊操做
        return true;
    }

    public boolean login(User user) {
        // 登陸操做
        return true;
    }

    public boolean logout(User user) {
        // 註銷操做
        return true;
    }

}
複製代碼

第二種實現方式

有人又說，不是說單一職責麼？從業務操做考慮，須要把註冊、登陸、註銷分開

class UserRegisterBiz {

    public boolean register(User user){
        // 註冊操做
        return true;
    }

}

class UserLoginBiz {

    public boolean login(User user) {
        // 登陸操做
        return true;
    }

}

class UserLogoutBiz {

    public boolean logout(User user) {
        // 註銷操做
        return true;
    }

}
複製代碼

感受像是在擡槓，其實這個沒有好壞之分，根據具體業務具體分析，你說你的登陸、註冊、註銷操做代碼不少，須要分開，那就分開，無可厚非。

好處

類的複雜性下降，實現什麼職責都有清晰明確的定義
可讀性提升，複雜性下降，那固然可讀性提升了
可維護性提升，可讀性提升，那固然更容易維護了
變動引發的風險下降，變動是必不可少的，若是接口的單一職責作得好，一個接口修改只對相應的實現類有影響，對其餘的接口無影響，這對系統的擴展性、維護性都有很是大的幫助 (來自《設計模式之禪》)