單一職責原則_ZenDei技術網路在線

個人博客原文： "單一職責原則" 設計模式六大原則之一：單一職責原則簡介姓名：單一職責原則英文名：Single Responsibility Principle 座右銘：There should never be more than one reason for a class to c ...

個人博客原文：
單一職責原則

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

簡介

姓名：單一職責原則
英文名 ：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;
    }

}

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

好處

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