單一職責原則

LieBrother發表於2019-02-25

個人部落格原文：
單一職責原則

景

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

簡介

姓名 ：單一職責原則

英文名 ：Single Responsibility Principle

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

脾氣 ：一個字“拽”，兩個字“特拽“

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

個人介紹 ：在這個人兼多責的社會裡，我顯得那麼的特立獨行，殊不知，現在社會上發生的很多事情都是因為沒有處理好職責導致的，比如，經常有些父母帶著小孩，一邊玩手機，導致小孩弄丟、發生事故等等

單一職責應用範圍

單一職責原則適用的範圍有介面、方法、類。按大家的說法，介面和方法必須保證單一職責，類就不必保證，只要符合業務就行。

方法

設想一下這個場景：假設我們要做一個使用者修改名字以及修改密碼的功能，可以有多種實現方案，比如下面列舉 2 種實現方式

程式碼：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;
    }

}
複製程式碼

感覺像是在抬槓，其實這個沒有好壞之分，根據具體業務具體分析，你說你的登入、註冊、登出操作程式碼很多，需要分開，那就分開，無可厚非。

好處

  1. 類的複雜性降低，實現什麼職責都有清晰明確的定義
  2. 可讀性提高，複雜性降低，那當然可讀性提高了
  3. 可維護性提高，可讀性提高，那當然更容易維護了
  4. 變更引起的風險降低，變更是必不可少的，如果介面的單一職責做得好，一個介面修改只對相應的實現類有影響，對其他的介面無影響，這對系統的擴充套件性、維護性都有非常大的幫助
    (來自《設計模式之禪》)

總結

這個單一職責原則，目的就是提高程式碼的可維護性、可讀性、擴充套件性，如果為了單一職責而破壞了這 3 個特性，可能會得不償失。

參考資料：《大話設計模式》、《Java設計模式》、《設計模式之禪》、《研磨設計模式》、《Head First 設計模式》

希望文章對您有所幫助，設計模式系列會持續更新，感興趣的同學可以關注公眾號，第一時間獲取文章推送閱讀，也可以一起交流，交個朋友。

公眾號之設計模式系列文章

公眾號

相關文章