Moment For Technology

How to understand the single responsibility principle in Java design patterns?

Posted on Dec. 2, 2022, 8:06 p.m. by Ms. Brenda Finch
Category: The back-end Tag: The back-end java

How do we understand the Single Responsibility principle (SRP) of the Java design pattern in the course of a real project?

Today we're going to look at the first principle of SOLID: the single responsibility principle.

The Single Responsibility Principle is abbreviated as SRP. A class or module should have A single responsibility. If we translate this into Chinese, it is: a class or module is responsible for only one responsibility (or function).

Note that this principle describes two objects, a class and a module. There are two ways to think about these two concepts in this column. One way to think about it is to think of a module as a more abstract concept than a class. Classes can also be thought of as modules. Another way to think about it is to think of a module as a coarser grained block of code than a class. A module contains multiple classes that make up a module.

Either way, the principle of single responsibility applies to both descriptions. For your convenience, I'll show you how to apply this design principle only in terms of "class" design. For "modules," you can use your own extension.

The definition of the single responsibility principle is very simple and not difficult to understand. A class performs only one responsibility or function. In other words, don't design large and complete classes; design small, single-function classes. To put it another way, if a class contains two or more business-unrelated functions, it is not simple enough and should be broken up into more simple, fine-grained classes.

Let me give you an example to illustrate. For example, a class may contain both the actions of the order and the actions of the user. Whereas orders and users are two separate business domain models, we violate the single responsibility principle by putting two unrelated functions in the same class. To satisfy the single responsibility principle, we need to split this class into two more granular and single functional classes: the order class and the user class.

Is the responsibility of the class designed as simple as possible? In order to satisfy the single responsibility principle, is the class as small as possible? The answer is no. Let's do it with an example. The Serialization class implements the Serialization and dissequencing of a simple protocol as follows:


/** * Protocol format: identifier-string; {gson string} * For example: UEUEUE; {"a":"A","b":"B"} */

public class Serialization {

  private static final String IDENTIFIER_STRING = "UEUEUE;";

  private Gson gson;



  public Serialization(a) {

    this.gson = new Gson();

  }



  public String serialize(MapString, String object) {

    StringBuilder textBuilder = new StringBuilder();

    textBuilder.append(IDENTIFIER_STRING);

    textBuilder.append(gson.toJson(object));

    return textBuilder.toString();

  }



  public MapString, String deserialize(String text) {

    if(! text.startsWith(IDENTIFIER_STRING)) {return Collections.emptyMap();

    }

    String gsonStr = text.substring(IDENTIFIER_STRING.length());

    returngson.fromJson(gsonStr, Map.class); }}Copy the code

If we wanted to make the responsibility of the class more singular, we would split the Serialization class further, splitting it into one Serializer class that does the Serialization job and another Deserializer class that does the deserialization job. The concrete code after the split is as follows:

public class Serializer {

  private static final String IDENTIFIER_STRING = "UEUEUE;";

  private Gson gson;


  public Serializer(a) {

    this.gson = new Gson();

  }



  public String serialize(MapString, String object) {

    StringBuilder textBuilder = new StringBuilder();

    textBuilder.append(IDENTIFIER_STRING);

    textBuilder.append(gson.toJson(object));

    returntextBuilder.toString(); }}public class Deserializer {

  private static final String IDENTIFIER_STRING = "UEUEUE;";

  private Gson gson;



  public Deserializer(a) {

    this.gson = new Gson();

  }



  public MapString, String deserialize(String text) {

    if(! text.startsWith(IDENTIFIER_STRING)) {return Collections.emptyMap();

    }

    String gsonStr = text.substring(IDENTIFIER_STRING.length());

    returngson.fromJson(gsonStr, Map.class); }}Copy the code

Although the split of Serializer and Deserializer makes the responsibilities of the two classes more simple, it also brings new problems. If we change the protocol format, data id from "UEUEUE" to "DFDFDF", or serialization mode from JSON to XML, then both Serializer and Deserializer need to be modified accordingly. The code is clearly less cohesive than the original Serialization. In addition, if we only change the protocol of Serializer and forget to change the code of Deserializer, then serialization and deserialization will not match, and the program will run incorrectly. In other words, after the split, the maintainability of the code will become worse.

In fact, whether applying design principles or design patterns, the ultimate goal is to improve code readability, extensibility, reusability, maintainability, and so on. It can also be used as a final consideration when considering whether it makes sense to apply a particular design principle.

How to understand the Single Responsibility Principle (SRP)?

A class performs only one responsibility or function. Don't design large and complete classes. Design small, single-function classes. The principle of single responsibility is to achieve high cohesion and low coupling of code, and improve the reusability, readability and maintainability of code.

More original reading: Javawu.com

Search
About
mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.