Simple Responsibility Pinciple (SRP) means that there should be no more than one reason for a class change. Suppose we have a class that is responsible for two responsibilities, and if requirements change, modifying the logical code of one responsibility could cause the functionality of the other responsibility to fail. Thus, there are two reasons for class changes in this class. How to solve this problem? Decouple the two responsibilities with two classes. Later requirement changes do not affect each other. Such a design can reduce the complexity of the class, improve the readability of the class, improve the maintainability of the system, reduce the risk caused by changes. In general, a class, interface, or method has only one responsibility.
Next, let’s look at code examples, again using lessons, which we have both live and recorded. Live classes can not be fast forward and fast back, recorded courses can be viewed repeatedly at will, different functions and responsibilities. Let’s create a Course class:
public class Course {
public void study(String courseName){
if("Live class".equals(courseName)){
System.out.println(courseName + "Can't fast forward.");
}else{
System.out.println(courseName + "You can go back and forth."); }}}Copy the codeLook at the calling code:
public static void main(String[] args) {
Course course = new Course();
course.study("Live class");
course.study("Recording class");
}
Copy the codeFrom the code above, the Course class assumes two kinds of processing logic. If you want to encrypt the course now, the encryption logic of the live and recorded course is different and you have to change the code. Changing the logic of the code is bound to affect each other, and it is easy to bring uncontrollable risks. We decoupled our responsibilities and looked at the code to create two classes: LiveCourse and ReplayCourse.
The code for the LiveCourse class is as follows:
public class LiveCourse {
public void study(String courseName){
System.out.println(courseName + "Can't fast-forward."); }} The ReplayCourse class looks like this:public class ReplayCourse {
public void study(String courseName){
System.out.println(courseName + "Can go back and forth."); }}Copy the codeThe call code is as follows:
public static void main(String[] args) {
LiveCourse liveCourse = new LiveCourse();
liveCourse.study("Live class");
ReplayCourse replayCourse = new ReplayCourse();
replayCourse.study("Recording class");
}
Copy the codeBusiness continues to grow, courses to do permissions. Students who do not pay can get basic information about the course, and those who have paid can get video stream, namely learning access. So there are at least two responsibilities at the level of controlling the curriculum. We can separate presentation and management responsibilities, both implementing the same abstract dependency. To design a top-level interface, create an ICourse interface:
public interface ICourse {
// Get basic information
String getCourseName(a);
// Get the video stream
byte[] getCourseVideo();
// Learn lessons
void studyCourse(a);
/ / refund
void refundCourse(a);
}
Copy the codeWe can split this interface into two interfaces: ICourseInfo and ICourseManager.
The code for the ICourseInfo interface is as follows:
public interface ICourseInfo {
String getCourseName(a);
byte[] getCourseVideo();
}
Copy the codeThe code for the ICourseManager interface is as follows:
public interface ICourseManager {
void studyCourse(a);
void refundCourse(a);
}
Copy the codeTake a look at the class diagram, as shown below.
Let’s look at single responsibility design at the method level. Sometimes we get lazy and write a method like this:
private void modifyUserInfo(String userName,String address){
userName = "Tom";
address = "Changsha";
}
Copy the codeIt might also be written like this:
private void modifyUserInfo(String userName,String... fileds){
userName = "Tom";
// address = "Changsha";
}
private void modifyUserInfo(String userName,String address,boolean bool){
if(bool){
}else{
}
userName = "Tom";
address = "Changsha";
}
Copy the codeObviously, the modifyUserInfo() method above takes on multiple responsibilities and can change both userName and address, or more, which clearly does not fit into a single responsibility. We make the following changes to split this method into two methods:
private void modifyUserName(String userName){
userName = "Tom";
}
private void modifyAddress(String address){
address = "Changsha";
}
Copy the codeAfter modification, it is simple to develop and easy to maintain. In actual development, we will have dependencies, combinations and aggregations of these relationships, as well as project size, cycle, level of technical staff, and control of schedule. Many categories do not conform to a single responsibility. However, as we went through the process of writing code, keeping interfaces and methods as single as possible helped us maintain them later in the project.
This article is “Tom play structure” original, reproduced please indicate the source. Technology is to share, I share my happiness! If this article is helpful to you, welcome to follow and like; If you have any suggestions can also leave a comment or private letter, your support is my motivation to adhere to the creation. Pay attention to “Tom bomb architecture” for more technical dry goods!
Other Design Principles
Open-closed Principle (OCP)
Dependence Inversion Principle (DIP)
Interface Segregation Principle (ISP)
Law of Demeter LoD
Liskov Substitution Principle (LSP)
Composite/Aggregate Reuse Principle, CARP