簡介

單一職責原則是最重要的設計原則，也是最抽象的設計原則。小到函式，大到平臺的設計，都可以使用單一職責原則來指導。也正因為它的抽象性，沒有一個統一的規則，不同的人即使是設計同一個功能，所劃分的函式、類也都是不相同的。

定義

單一職責原則，英文名稱 Single Responsibility Principle,意為每一個模組、類、函式應當只具備一個職責，也即只有一個功能。按照馬丁大叔的說法：“一個類的改變只有一個理由”。

這個原則只給了我們一個方向，就跟“聽過很多道理依然過不好這一生”中的道理一樣，為什麼依然過不好？因為道理僅僅是一個道理而不具備可操作性，沒有辦法按照步驟一二三來得到想要的結果。

單一不需要解釋，關鍵是職責，一個函式、介面、類、模組要幹多少活才算是職責單一？多大的粒度是合適的呢？

按照我現階段的知識水平，單一職責原則背後隱去的關鍵概念是抽象，函式、介面、類需要符合自己所在的抽象層次，在其自身所在的層面上內聚成領域，這就是自己的職責。

實踐

需求：做一個登入功能，要求有過濾黑名單，登入成功後傳送簡訊、郵件等功能。

注：僅示意

public class LoginManager {
    public String login(String userId, String password) {
        List<String> blacklist = blacklistService.findByUserId(userId);
        if(CollectionUtils.isNotEmpty) {
            return "user blocked";
        }
        
        User user = userService.findByUserId(userId);
        if (user == null) {
            return "user not exists";
        }
        
        String passwordMd5 = Md5Utils.md5(password);
        if (!passwordMd5.equals(user.getPassword()) {
            return "user login failed";
        }
        
        String uuid = UUIDUtils.getUUID();
        cacheService.set(uuid, userId);
        setCookie("sessionId", uuid);
        
        // mail related logic
        String mailContent = user.getUserName + "! Welcome back. From mail."
        mailService.send(user.getMail(), mailContent);
        
        // msg related logic
        String smsContent = user.getUserName + "! Welcome back. From sms."
        smsService.send(user.getPhone(), smsContent);
        
        return "success";
    }
}

 

函式

這個功能從函式名來看，並沒有違反單一職責的原則，登入就是需要做這麼多的事。但是從編碼實現來說，已經違反了SRP。登入包含的職責有過濾、校驗，但是過濾、校驗的具體細節並不在登入函式的職責範圍內，據此重構登入函式

public class LoginManager {
    public String login(String userId, String password) {
        Pair<Boolean, String> check = loginCheck(userId, password);
        if (!check.left()){
            return check.right();
        }
        
        saveUserSesssion(userId);
        afterLogined(userId);
        
        return "success";
    }
    
    private Pair<Boolean, String> loginCheck(String userId, String password) {
        
        Pair<Boolean. String> beforeCheck = loginBeforeCheck(userId);
        if(!before.left()){
            return beforeCheck;
        }
        
        return userCheck(userId, password);
    }
    
    private Pair<Boolean, String> loginBeforeCheck(String userId){
        List<String> blacklist = blacklistService.findByUserId(userId);
        if(CollectionUtils.isNotEmpty) {
            return Pair.of(false, "user blocked");
        }
        
        return Pair.of(true, "");
    }
    
    
    private Pair<Boolean, String> userCheck(String userId, String password){
        User user = userService.findByUserId(userId);
        if (user == null) {
            return Pair.of(false, "user not exists");
        }
        
        String passwordMd5 = Md5Utils.md5(password);
        if (!passwordMd5.equals(user.getPassword()) {
            return Pair.of(false, "user login failed");
        }
        
        return Pair.of(true, "");
    }
    
    private void saveUserSesssion(String userId){
        String uuid = UUIDUtils.getUUID();
        cacheService.set(uuid, userId);
        setCookie("sessionId", uuid);
    }
    
    private void afterLogined(User user) {
        User user = userService.findByUserId(userId);
        sendMail(user);
        sendSms(user);
    }
    
    private void sendMail(User user) {
        // mail related logic
        String mailContent = user.getUserName + "! Welcome back. From mail."
        mailService.send(user.getMail(), mailContent);
    }
    
    private void sendSms(User user) {
        // msg related logic
        String smsContent = user.getUserName + "! Welcome back. From sms."
        smsService.send(user.getPhone(), smsContent);
    }
}
 

重構完成後，如果需要增加過濾條件，則只需要修改loginBeforeCheck 函式，如果需要增加登入後功能，則只需要修改 afterLogined 函式，每個函式都只有一個修改的理由，也即符合 SRP 原則。

類與介面

當我們將功能從函式的粒度重構之後，每個函式只負責了自己的部分，已經符合了 SRP 原則，但是從類的角度來看，登入類承擔了太多的功能。增加校驗規則需要修改登入類，增加登入後的功能也需要修改登入類，因此類也需要按照 SRP 的原則來進行重構。

在思考函式重構的過程中，我們已經對如何劃分類有了思考。校驗可以抽出來，登入後發簡訊、郵件也可以抽出來，這樣登入類就符合了自己的名稱：僅關心登入的細節。

public interface LoginCheckService {
    public Pair<Boolean, String> check(String userId, String password);
}

public interface LoginListener{
    public void afterLogin(LoginEvent event);
}

光有這兩個類可能是不夠的，我們還需要定義一個登入事件LoginEvent， 事件註冊中心 Registry, 事件分發Dispatcher, LoginCheckService 是有先後順序的要求的，可以實現一個 Order 介面，也可以拆成兩個介面，同一個介面的實現沒有順序要求。這完全取決於我們系統功能的規模，和我們對職責的認識。

模組

雖然登入功能一般不會做成模組，但我們可以站在模組的角度來思考。模組是大家共用的依賴，對於可擴充套件性、可維護性要求會比一個功能要求更高。在 類和介面 小節的描述中，事件、註冊中心等在功能層面上可能不是必須的，在模組層面上，這些是必須的。沒有事件，使用方就不知道如何響應；沒有註冊中心，使用方就不知道如何定製化；沒有事件分發，模組就無法將事件通知到使用方。

缺點

SRP 可以很好的將我們的功能、應用解耦，但是應該看到 SRP 存在的缺點，才可以更好的權衡自己的設計。

• 不明確。職責的含義沒有明確界定，如何界定是門藝術。
• 無評判標準。界定出來的職責是好是壞？沒有標準，只有經驗。
• 易濫用。職責劃分到最後可能就是一個介面一個方法，看似符合 SRP，實則是 SRP 的濫用。
• 函式、介面、類爆炸。
• 知識比較支離。資訊分佈在各個類中，不如放在一起集中。

後記

要做一個符合SRP 原則的設計是很困難的，需要我們在實踐中總結經驗。對一個領域有了充分的瞭解，我們才能更加遊刃有餘的應用SRP 原則。同時不要濫用 SRP原則，程式設計是門藝術，設計更是一門藝術。

個人

個人公眾號

相關推薦