Single responsibility principle: a class, only one reason that causes its change.
Why is the single responsibility principle required?
If a class has multiple reasons to modify it, then modifying a function may cause bugs to other functions, so it is best to have only one responsibility for a class. But it is still difficult to achieve in practical applications, so we can only try our best to comply with this principle.
Sometimes, developers will have some problems when designing interfaces, such as the user's properties and user behavior being declared in an interface. This causes the business object and business logic to be put together, which causes the interface to have two responsibilities. The interface responsibilities are unclear, and according to the definition of SRP, it violates the principle of single responsibilities of the interface.
Here is an example:
package com.loulijun.chapter1; public interface Itutu { //height void setShengao(double height); double getShengao(); //weight void setTizhong(double weight); double getTizhong(); //eat boolean chiFan(boolean hungry); //on the Internet boolean shangWang(boolean silly); }The above example has this problem. Height and weight belong to the business object, and the corresponding method is mainly responsible for the user's attributes. Eating and surfing the Internet are the corresponding business logic, which is mainly responsible for the user's behavior. But this will give people the feeling that they don’t know what this interface is doing, the responsibilities are not clear, and various problems will also be caused during later maintenance.
Solution: The principle of single responsibility, break this interface into two interfaces with different responsibilities.
ItutuBO.java: Responsible for the attributes of tutu (tutu, if it is a personal name)
package com.loulijun.chapter1; /** * BO: Business Object, Business Object* Responsible for the user's attributes* @author Administrator * */ public interface ItutuBO { //Height void setShengao(double height); double getShengao(); //Weight void setTizhong(double weight); double getTizhong(); }ItutuBL.java: Responsible for placing
package com.loulijun.chapter1; /** * BL:Business Logic, Business Logic* Responsible for user behavior* @author Administrator * */ public interface ItutuBL { //Eat a meal boolean chiFan(boolean hungry); //Entertainment boolean shangWang(boolean silly); }This realizes the single responsibility of the interface. Then when implementing an interface, there are two different classes
TutuBO.java
package com.loulijun.chapter1; public class TutuBO implements ItutuBO { private double height; private double weight; @Override public double getShengao() { return height; } @Override public double getTizhong() { return weight; } @Override public void setShengao(double height) { this.height = height; } @Override public void setTizhong(double weight) { this.weight = weight; } }TutuBL.java
package com.loulijun.chapter1; public class TutuBL implements ItutuBL { @Override public boolean chiFan(boolean hungry) { if(hungry) { System.out.println("Go to have hot pot..."); return true; } return false; } @Override public boolean shangWang(boolean silly) { if(silly) { System.out.println("So boring, go to the Internet..."); return true; } return false; } }This makes it clear. When you need to modify the user attributes, you only need to modify the ItutuBO interface, which will only affect the TutuBO class and will not affect other classes.
Summarize:
1. The actual situation is that many times we cannot foresee the "cause of the change" in advance, so we can only construct our interface based on experience and try to ensure that one interface has only one responsibility. What we are talking about here is interfaces. Classes may inherit and implement multiple interfaces, making it more difficult to achieve a single responsibility.
2. When the classes I wrote before have had multiple reasons for the change, it is best to refactor it.
However, there is a problem with the principle of using the single responsibility. There is no clear division standard for "responsibilities". If responsibilities are divided too detailed, it will lead to a sharp increase in the number of interfaces and implementation classes, which will increase the complexity and reduce the maintainability of the code. Therefore, when using this responsibility, we must also analyze the specific situation. The suggestion is that the interface must adopt the single responsibility principle, and realize the single responsibility principle as much as possible in the design of the class. It is best to cause changes in a class if one reason is caused.