Simply explain the single responsibility principle in Java design pattern programming _java

Single Responsibility Principle: a class that has only one cause for its change.

Why do we need a single responsibility principle?
If a class has multiple reasons to modify it, then modifying a feature may cause other functions to produce bugs, so a class is best to have only one responsibility. But the actual application is still more difficult to achieve, we can only try to conform to this principle.

Sometimes, developers design interfaces with problems, such as the user's attributes and the user's behavior being placed in an access statement. This creates a business object and business logic that is put together, causing the interface to have two responsibilities, ambiguous interface responsibilities, and violating the single responsibility principle of the interface according to the SRP definition.

Here's an example:

Package com.loulijun.chapter1; 
  
Public interface Itutu { 
  //height 
  void Setshengao (double height); 
  Double Getshengao (); 
  Weight 
  void Settizhong (double weight); 
  Double Gettizhong (); 
  Eat a 
  Boolean Chifan (Boolean hungry); 
  Internet 
  Boolean Shangwang (Boolean silly); 
 

The above example has this problem, height, weight belongs to the business object, and the corresponding method is mainly responsible for the user's attributes. While eating, surfing the internet is the corresponding business logic, mainly responsible for the user's behavior. But this will give people a kind of do not know what the interface is to do what the feeling, responsibility is not clear, later maintenance will also cause a variety of problems.

Solution: A single responsibility principle that breaks down this interface into two different interfaces

Itutubo.java: Responsible for the attributes of Tutu (TU, if it is a person's name)

Package com.loulijun.chapter1; 
  
/** 
 * Bo:bussiness object, business object 
 * Responsible for 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 the coating behavior

Package com.loulijun.chapter1; 
/** 
 * bl:business Logic, business logic 
 * Responsible for user behavior 
 * @author Administrator 
 */public 
interface ITUTUBL { 
  //Eat a 
  Boolean Chifan (Boolean hungry); 
  Internet 
  Boolean Shangwang (Boolean silly); 
 

This achieves a single responsibility for the interface. So when implementing an interface, you need to have 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 ("To eat hotpot ..."); 
      return true; 
    } 
    return false; 
  } 
  
  @Override Public 
  Boolean Shangwang (Boolean silly) { 
    if (silly) 
    { 
      System.out.println ("Good boring, on the net ..."); 
      return true; 
    } 
    return false; 
  } 
  
} 

This makes it clear that when you need to modify user properties, you only need to modify the Itutubo interface, which only affects the Tutubo class and does not affect other classes.

Summarize:
1. The reality is that many times we cannot foresee "causes of change" in advance, so we can only construct our interfaces by experience, and try to do an interface with only one responsibility. Here is the interface, the class may have inherited and implemented multiple interfaces, more difficult to achieve a single responsibility.
2. When previously written classes already have multiple causes for change, we'd better do code refactoring.

However, the use of a single responsibility principle there is a problem, "responsibility" does not have a clear standard of demarcation, if the division of responsibilities too thin will lead to the number of interfaces and implementation classes, but increased complexity, reducing the maintainability of the code. Therefore, the use of this responsibility when the specific circumstances of the specific analysis. Recommendation is that the interface must adopt a single responsibility principle, the implementation of class design as far as possible to achieve a single responsibility principle, preferably a reason for a class change.