1.单一职责原则介绍2.单一职责原则用代码演示3.总结1.单一职责原则介绍定义：就一个类而言，应该有只是其变化的原因之一。即一个类只负责一个职责。问题描述：我们刚开始学习javaWeb的时候，那时候还没有学过MVC模式，自然而然会在doGet()/doPost()方法中加入各种代码，包括业务逻辑代码和连接代码到sql。也就是说不管什么需求变化，我们都要改这个方法，这样很不好，维护起来很麻烦，扩展性也很差。解决方案：MVC是单一职责的体现。Controller层负责具体业务模块流程的控制。Service层主要负责业务模块的逻辑应用设计。Dao层主要负责数据持久化层。2.用代码演示单一职责原则假设现在V1.0有一个需求：我们现在想获取一个用户的信息，我们可以像往常一样使用mapper查询：publicUsergetInfo(){Useruser=userMapper.getById(UserUtil.getCurrentUser().getId());returnuser;}现在这个方法符合单一职责原则，但是我们的需求变了：需求V2.0：由于现在是微服务开发，我们需要使用GET请求，从一个服务中获取一些额外的信息，然后返回到前端：publicUsergetInfo(){Useruser=userMapper.getById(UserUtil.getCurrentUser().getId());ExtraMsgextraMsg=HttpRequest.get("/get/user/info").body(JSONObject.toJSONString(user.getId())).execute().body();user.setExtraMsg(extraMsg);returnuser;}此时，这个方法包含了两个职责，职责一：获取用户基本信息职责二：调用get请求获取附加信息，然后让用户信息被设置。这就是所谓的责任分散。所谓责任扩散，是指由于某种原因，一个原本只负责一个责任的类，需要承担更多的责任。我举的例子很简单，但真实场景可能更复杂。如果其他类需要调用该方法获取额外信息，则需要重新重写，违反了单一职责原则。这个时候我们还不如直接把它分开。每个方法只负责一个职责。解决方案：去掉get请求方法。publicUsergetInfo(){Useruser=userMapper.getById(UserUtil.getCurrentUser().getId());ExtraMsgextraMsg=getExtraMsg(user.getId());user.setExtraMsg(extraMsg);returnuser;publicExtraMsggetExtraMsg(StringuserId){返回HttpRequest.get("/get/user/info").body(JSONObject.toJSONString(user.getId())).execute().body();}3总结一下，如果一个类（方法）承担了太多的职责，相当于把这些职责耦合在一起。当需求发生变化时，设计将遭受意想不到的破坏。所以，我们要发现职责，分离职责，那么就只有一个类（方法）职责了。遵循单一职责原则的好处是：1）可以降低类的复杂度，提高代码的可读性，因为职责减少了，逻辑和可读性肯定比多重职责简单很多。2）当需求发生变化时，如果合理遵循单一职责原则，可以降低该功能的影响。
