关于java:深入浅出设计模式单一职责原则

1. 繁多职责准则介绍

2. 用代码演示繁多职责准则

3. 总结

1. 繁多职责准则介绍
定义：就一个类而言，应该只有一个引起它变动的起因。就是说，一个类只负责一项职责。

问题形容：咱们在刚刚开始学习 javaWeb 的时候，那个时候还没有学习 MVC 模式，自然而然地就会往 doGet()/doPost()办法里减少各种代码，有业务逻辑代码，也有连贯 sql 的代码，这就意味着，无论任何需要更改，咱们都须要更改这个办法，这是很蹩脚的，保护十分麻烦，也十分不足拓展性。

解决办法：MVC 就是一个繁多职责的体现，Controller 层负责具体的业务模块流程的管制，Service 层次要负责业务模块的逻辑利用设计，Dao 层次要是做数据长久层的工作。

2. 用代码演示繁多职责准则

假如当初有一个需要 V1.0：咱们当初要获取一个用户的信息，咱们就依照平时开发的应用 mapper 进行查问就能够了：

public User getInfo(){User user = userMapper.getById(UserUtil.getCurrentUser().getId());
    return user;
}

当初这个办法是合乎繁多职责准则的，然而咱们需要进行了更改：

需要 V2.0：因为当初是微服务开发，咱们须要应用 GET 申请，从一个服务中，获取额定的一些信息，并且返回给前端：

public User getInfo(){User user = userMapper.getById(UserUtil.getCurrentUser().getId());

    ExtraMsg extraMsg = HttpRequest.get("/get/user/info")
        .body(JSONObject.toJSONString(user.getId()))
         .execute().body();
    user.setExtraMsg(extraMsg);
    return user;
}

此时，这个办法就蕴含了两个职责，
职责 1：获取 user 根本信息
职责 2：调用 get 申请，获取额定的信息，再让设置 user 信息。

这就是所谓的职责扩散，所谓职责扩散，就是因为某种原因，原本只负责一个职责的类须要负责更多的职责。

我举的例子很简略，然而实在场景可能更为简单，如果其它类还须要调用获取额定信息的办法，须要再重写一次，又违反了繁多职责准则，此时咱们不如间接将它剥离进去，每个办法只负责一个职责。

解决办法：将 get 申请的办法剥离进去。

public User getInfo(){User user = userMapper.getById(UserUtil.getCurrentUser().getId());

    ExtraMsg extraMsg = getExtraMsg(user.getId());
    user.setExtraMsg(extraMsg);
    return user;

public ExtraMsg getExtraMsg(String userId){return HttpRequest.get("/get/user/info")
        .body(JSONObject.toJSONString(user.getId()))
         .execute().body();
}

3. 总结
如果一个类（办法）承当的职责过多，就等于把这些职责耦合在一起，需要变动时，设计会蒙受到意想不到的毁坏，所以，咱们就要去发现职责和拆散职责，那么这个类（办法）就只有一个职责。

遵循繁多职责原的长处有：
1）能够升高类的复杂度，进步代码的可读性，因为职责缩小，逻辑和可读性必定比多项职责简略很多。
2）需要变更的时候，如果繁多职责准则遵循地正当，能够升高该性能的影响。