SingleResponsibility（简单责任原则，SRP）是指类变化的原因不应该超过一个。假设我们有一个类负责两个职责。一旦需求发生变化，修改其中一个职责的逻辑代码，可能会导致另一个职责的功能出现故障。这样，这个类引起类变化的原因有两个。如何解决这个问题呢？用两个类来实现两个职责进行解耦。后期需求变更和维护互不影响。这样的设计可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更带来的风险。通常，一个类、接口或方法只负责一个职责。接下来我们看代码示例，还是以课程为例。我们的课程有直播和录制课程。直播课程不能快进快退，录播课程可以随意反复观看，功能和职责不同。或者先创建一个Course类：}else{System.out.println(courseName+"可以反复看");}}}}查看调用代码：publicstaticvoidmain(String[]args){Coursecourse=newCourse();course.study("直播课");course.study("recordedclass");}从上面的代码来看，Course类承担了两个处理逻辑。如果现在要加密课程，直播课程和录播课程的加密逻辑不同，需要修改代码。修改代码的逻辑势必会相互影响，很容易带来不可控的风险。让我们解耦职责，查看代码，并创建两个类：LiveCourse和ReplayCourse。LiveCourse类代码如下：publicclassLiveCourse{publicvoidstudy(StringcourseName){System.out.println(courseName+"cannotfast-forward");}}ReplayCourse类的代码如下：publicclassReplayCourse{publicvoidstudy(StringcourseName){System.out.println(courseName+"可重复返回");}}调用代码如下：publicstaticvoidmain(String[]args){LiveCourseliveCourse=newLiveCourse();liveCourse.study("直播课");重播课程replayCourse=newReplayCourse();replayCourse.study("录播课");}业务不断发展，课程必须授权。未付费的学生可以获得基础课程信息，付费的学生可以获得视频流，即学习权。那么在控制类层面至少有两个职责。我们可以将表示责任与管理责任分开，两者都实现相同的抽象依赖。设计顶层接口，创建ICourse接口：publicinterfaceICourse{//获取基本信息StringgetCourseName();//获取视频流byte[]getCourseVideo();//学习课程voidstudyCourse();//RefundvoidrefundCourse();}我们可以把这个接口拆成两个接口：ICourseInfo和ICourseManager。ICourseInfo接口的代码如下：publicinterfaceICourseInfo{StringgetCourseName();byte[]getCourseVideo();}ICourseManager接口代码如下：publicinterfaceICourseManager{voidstudyCourse();voidrefundCourse();}看一下类图，如下图。我们来看看方法层面的单一职责设计。有时候我们会偷懒，写一个方法如下：privatevoidmodifyUserInfo(StringuserName,Stringaddress){userName="Tom";address="Changsha";}也可以这样写userName,Stringaddress,booleanbool){if(bool){}else{}userName="Tom";address="Changsha";}显然，上面的modifyUserInfo()方法承担了多重职责。可以修改userName，address，甚至更多，这显然不符合单一职责。我们做如下修改，将这个方法拆成两个方法：privatevoidmodifyUserName(StringuserName){userName="Tom";}privatevoidmodifyAddress(Stringaddress){address="长沙";}开发，易于维护。在实际开发中，我们会有项目依赖、组合、聚合等关系，以及项目规模、周期、技术人员水平、进度控制等关系。许多类别不符合单一职责。但是在写代码的过程中，我们尽量保持接口和方法的职责单一，这对项目后期的维护有很大的帮助。本文为《汤姆炸弹建筑》原创，转载请注明出处。科技在于分享，我分享我的快乐！如果本文对您有帮助，请关注并点赞；有什么建议也可以留言或私信。您的支持是我坚持创作的动力。关注微信公众号“汤姆炸弹架构”，获取更多技术干货！【推荐】汤姆炸弹架构：收藏此文相当于收藏一本《设计模式》书其他设计原则汤姆炸弹架构：开闭原则（OCP）汤姆炸弹架构：接口隔离原则（InterfaceSegregationPrinciple，ISP）汤姆炸弹架构：Dimiter原则（LawofDemeterLoD）汤姆炸弹架构：LiskovSubstitutionPrinciple(LSP)汤姆炸弹架构：Composite/AggregateReusePrinciple(CARP)
