The role of the principle of object responsibility clarification in the program - code specification

Basic object-oriented principles:

  • The principle of single responsibility (the principle of clear object responsibility)
    requires that an object only do one thing well and must focus on it. If there are too many reasons for changes, the program will be unstable. (high cohesion, low coupling extension)

The following is an introduction based on the principle of single responsibility: the
principle of clear responsibility is like learning courses during school. Chinese teachers only need to teach students Chinese, and mathematics teachers only need to teach students mathematics, but Chinese teachers can also teach us mathematics, so why only teach Chinese, do not teach mathematics? This is just like the object-oriented principle of clarifying responsibilities . A teacher only teaches one class, and an object only does one thing well. A teacher is equivalent to an object.
Then at this time we can think about it, that one teacher can also teach multiple courses, for example, in some places, one teacher has to teach multiple courses. Just like in the program, the front-end and back-end codes (the front-end interface operation code and the back-end data access code are both a form of object) can also be placed in one place, and no error will be reported when running the project. But this is a violation of the object-oriented single responsibility principle

Here is a description of the problem of writing code that does not follow the principle of clear responsibilities:
Here is a description of the problems of not writing code in accordance with the principle of clear responsibilities
In short:
the front-end only writes the front-end code, and the back-end only writes the code for data access to the database. The front-end does not need to understand how the back-end connects to the database and operates data. , the backend does not need to know what the frontend calls the backend method to do. Just like the Chinese teacher does not need to know what the math teacher teaches, and vice versa.

Let's analyze it through the code:
This is the case when the front and back ends are not separated:
insert image description here
then let's think about it at this time, when the front and back ends are together, it does not conform to the principle of single responsibility . Because this is the front-end, then we have to separate the back-end code from it. In fact, this is the prototype of our three-tier architecture. Students who have used the three-tier architecture should know what to do next. In fact, it is to put the back-end data access code into another class. We can build a separate folder for this data access layer, separate it from the front-end, and name it DAL layer.

The following is the changed front-end code:
insert image description here
Changed back-end code:
insert image description here
summary of principles of clear responsibilities:

*Principle:
----Separate "interface code" and "data access code"
*Benefits:
----No matter what type of application (b/s, c/s) when the interface changes, data access Part generally does not need any changes - at the same time, front- end
designers and background writers can be well separated There should also be no other business logic code. *Expansion: ----The principle of clear object responsibilities lays the foundation for the subsequent study of "three-tier architecture"



Summary: This seems to be more complicated than before the separation. Is
it really worth it (this question was a question I had when I first came into contact with the three-tier architecture).
You may not feel the obvious difference when coding, but when there are hundreds or thousands of such file classes in the project, do we still have to write like this? How much will the maintenance and expansion cost in the later stage of our project be? Therefore, we need to understand not only the original meaning of these principles (the principle of clear responsibilities) and characteristics (high cohesion, low coupling) in our project architecture, but also the intention behind this design.
ok, call it a day!

Guess you like

Origin blog.csdn.net/qq_37213281/article/details/119905727