Shulou(Shulou.com)06/03 Report--

The main content of this article is to explain "why the responsibilities of the class should be simplified", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn why the responsibilities of the class should be simplified.

Principle of single responsibility

There should be only one reason for a class to change

Opening and closing principle

Software entities should be extensible, not modifiable. That is, it is open to extensions and closed to modifications. This principle is the most abstract and difficult to understand among the many principles of object-oriented programming.

Richter's substitution principle

All references to the base class must be able to transparently use the objects of its subclass, in other words, the subclass can be replaced with a subclass wherever the base class is referenced.

Principle of dependency inversion

In fact, the details of this principle can be summarized into two points:

High-level modules should not directly rely on the underlying modules, but should rely on abstraction

Abstraction should not depend on concrete implementation, which should depend on abstraction.

Interface isolation principle

A program does not rely on interfaces that it does not use; in other words, a program depends only on the interfaces it needs.

Conceptually, the single responsibility principle is the easiest to understand, as boring as a singleton pattern in a design pattern, isn't it?

Whose duty?

To tell you the truth, I have read many articles explaining the design principle of "single responsibility", all of which are elaborated on the basis of category. In fact, I don't think it is right. The single responsibility design principle is essentially an idea of software design principle, which has guiding significance. As for whose responsibility needs to be single, it is a pseudo-proposition, which not only refers to the classes in object-oriented programming, the modules of the system, and even micro-services should follow this rule in architecture design.

In the understanding of object-oriented design, the most basic component unit of the program is class, multiple classes compose modules (module), multiple modules compose services (service), and multiple services compose systems (system). The above concepts will exist in general software systems.

Whether it is a class, a module, a service, or a system, I think it is necessary to ensure a "single responsibility" when designing.

Is it really easy to be single

When it comes to "single" responsibility, everyone has a different view.

Class UserInfo {/ / user id public int UserId {get;set;} / user login account public string Account {get;set;} / user login password public string Pwd {get;set;} / / user name public string Name {get;set;}}

The above is the most common user information entity, do you think it has a single responsibility? Let me talk about my own opinion:

From the point of view of user information, this class represents user information, it is single, this is also the view of most people, is there anything wrong? Actually, it is. Because in the current scenario, it really is.

With the development of business, the user's information fields will be more and more, such as: user's age, gender, education. Wait. Looking at the larger and larger UserInfo classes, should we split them?

At this time, I think you can split it according to the type of user information. After all, large and complete classes are not good. How do you split it? For example, the type of user authentication can be split according to the user login scenario.

Class UserAuth {/ / user id public int UserId {get;set;} / user login account public string Account {get;set;} / user login password public string Pwd {get;set;}}

The basic user information and user extended information can be separated according to the frequency and importance of user information in the system.

Class UserBasicInfo {/ / user id public int UserId {get; set;} / user name public string Name {get; set;} / user Mobile number public string Phone {get; set;} / other basic attributes} class UserExtendnfo {/ / user email address public string Email {get; set;} / user QQ number public string QQ {get; set;} / other attributes}

Of course, I'm just giving a chestnut here. If the user's Email is as common as the mobile phone number, you can add the Email attribute to the basic attribute.

The above is just a chestnut split according to different uses, taking user information as an example. In different business backgrounds and different business stages, the split of the same class may be very different. Sometimes, what you think of as "right" will slowly become "wrong" with the development of the system, of course, this "mistake" is not terrible, after all, the architecture of the system is slowly iterated out.

In short, to evaluate whether a class must meet a single principle, there is no unified standard and specification, and in actual development, there is no need for over-design. At the beginning of the project, it can be a large and comprehensive class that meets business needs. With the development of the business, you are bound to go through the process of split, which is also the inevitable stage of software development.

The above is only for the class, the most basic object-oriented unit to chat, rise to the module and the system is the same reason, micro-service also appears with the continuous evolution of software development, in fact, from the responsibility point of view, micro-service is also the product of the principle of single responsibility, and this single is more inclined to business oneness, not functional oneness.

Is it better to split the duties as carefully as possible? I don't think so. When a class or module or even a system is split into too much detail, it will face the problem of maintenance. For example, when there are too many micro services, it will face a series of problems such as governance. This is also one of the problems that K8s has to solve.

Split principle

In the final analysis, although it is difficult to make an accurate subjective judgment on a single responsibility, there are still some general rules that can be used for reference. Here we take classes as an example.

High cohesion. When the system modifies any function, it only needs to modify one place. If you need to modify more than one place to meet a certain requirement, it is very likely that the division of your responsibilities is unreasonable.

Too many attributes. When a class has too many attributes, you can consider splitting the class into responsibilities. And as for how many is more? When looking for an attribute gives you a headache, it has reached the point where it can be split (self-made up)

Too much dependence. When there are too many dependent resources in a type, it can be split

Independent change. When some properties of a class are heavily used and change frequently, you can consider splitting these attributes into separate classes.

When it comes to single responsibility, by the way, the design of the interface should follow the principle of single responsibility. The interface is essentially an abstraction of business, and different businesses should be abstracted into different interfaces to ensure that each class, each module, each system can be expanded independently.

At this point, I believe you have a deeper understanding of "why the responsibilities of the class should be simplified". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.