Java geek
Related reading:
JAVA programming ideas (1) Increase extensibility through dependency injection (2) How to program for interface (3) Remove the ugly if, self-registration strategy mode elegant meet the open and close principle (4) JAVA programming ideas (Builder mode) classical paradigm and factory mode how to choose? Java Programming Ideas (5) Event Notification Decoupling Process (6) Event Notification Decoupling Process (7) Scenarios using Composition and Inheritance Java Basics (1) Simple and thorough understanding of inner classes and static inner classes Java basics (2) Memory optimization – Using Java references for caching JAVA foundation (3) ClassLoader implementation hot loading JAVA foundation (4) enumeration (enum) and constant definition, factory class use contrast JAVA foundation (5) functional interface – reuse, The sword of decoupling HikariPool source code (2) Design idea borrowed from JetCache source code (1) beginning JetCache source code (2) Top view people in the workplace (1) IT big factory survival rules
1. How to understand single responsibilities
First, the “one” of a single responsibility does not refer to a single responsibility, but to a class of responsibilities. For example, Java back-end calls are typically divided into three classes:
The String utility class, the Date utility class, and the File utility class, each of which takes on a class of responsibilities, allow multiple methods in each class.
Corresponding to life, police, doctors, teachers all assume a kind of duty, but they can do a lot of specific things.
Therefore, when designing a class, methods that include a cohesive set of methods that can be assigned to a particular category can be considered to have a single responsibility.
2. Benefits of a single responsibility
If you are a developer, can you do both at the same time? Some people may say, I am a full stack, can handle everything, then let you do UI prototyping, JAVA, C++, GO development, mobile, cloud automation and performance testing, can you handle it? Or which company has senior full-stack engineers?
As a result, one person can’t do everything, and it is possible to achieve top level only in one direction, such as development, architecture, testing, and project management.
When the class responsibility is single, first of all, the possibility of change is small, corresponding to stable; Second, it is easy to read and maintain (a book about finance and politics is unlikely to do both well). Moreover, the reduction in the number of callers corresponds to a reduction in coupling (think about whether a person who is both a doctor and a police officer must have more people to deal with than if he had only one duty).
So the benefits of a single responsibility are: stability, easy maintenance, and decoupling.
3. How to achieve a single responsibility
Achieving a single responsibility requires two considerations: cohesion and singleness.
Cohesion refers to putting together a group of similar functions, rather than forcing methods into different classes for a single responsibility.
For example, when a system/module provides external functions, it often uses a Facade as a design pattern. This pattern encapsulates some methods that need to be invoked externally into a class, so that the external can easily find the call entrance, rather than disassembling the functions in detail and not knowing where the method entrance is without looking at the documents.
The same goes for the Controller, Service, and DAO classes mentioned earlier. There is never a single method for each class, so a single responsibility doesn’t have to be very thin, just cohesive.
The single responsibility can be divided into the following aspects: 1. The non-business general part is abstracted and independent, such as: writing files, compression, encryption and decryption, accessing databases, sending messages, business rules algorithm (tax calculation, preferential calculation) and so on. 2. Divide by business domain, for example, customer, product, and order. 3. Divide according to hierarchical architecture, such as Controller, Service, and DAO mentioned above.
There are several principles to consider when dividing the responsibilities of each of these categories: 1. Whether a function can exist and change independently, as long as it can, can be dismantled. For example, the address and unit information of customers can exist and change independently, so they can be separated. For example, orders and order items need to be managed together because they depend on each other. 2. Whether business semantics can be independent. As long as the business semantics are independent, they can be separated out, which will be illustrated in a concrete example in the next article. 3. Cohesion. The Facade pattern mentioned above is an example of cohesion whose consideration is to facilitate the same external calls.
4. To summarize
1. The benefits of single responsibilities: stability, easy maintenance, and decoupling can greatly increase productivity, and every development should strive to do so.
2. In the final analysis, to achieve a single responsibility is to achieve cohesion in the division of class responsibilities and separate out the parts that can exist independently and change.
end.
