深入浅出设计模式——单一职责原则

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）需求变更的时候，如果单一职责原则遵循地合理，可以降低该功能的影响。