单一职责原则

我的博客原文： 单一职责原则

设计模式六大原则之一：单一职责原则

简介

姓名 ：单一职责原则

英文名 ：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 设计模式》

但愿文章对您有所帮助，设计模式系列会持续更新，感兴趣的同窗能够关注公众号，第一时间获取文章推送阅读，也能够一块儿交流，交个朋友。

公众号之设计模式系列文章