returns to the most essential and pursues the most basic! Discover the unchanging truths in the software world!
What is the principle? The
principle refers to a rationalized phenomenon derived from long-term experience summarization. ——Baidu Encyclopedia
principles are guiding, applicable, and unique .
Guidance: When hesitating whether to do something, you can make a decision based on your own principles, so Ray Dalio marked a book "Principles" based on his own behavior.
Applicability: People divide labor and cooperate in social groups to achieve self-survival and promote social development. In this long process, some people's consensus on words and deeds has gradually formed, such as repaying debts, killing people to pay for their lives, etc.
Difference: Everyone has different principles for something or a certain point of view or attitude. For example, investors will have different operating principles based on their understanding of stocks, market observations, and their own perceptions.
Why should we learn software design principles ? There is no silver bullet in
software design principles. They are rules summarized during the code development process, rather than naturally existing truths.
Learning design principles is like learning traffic rules. If coding is like driving a car, then design principles are like traffic rules. If you want your software to survive in the market, you need to make your cars obey traffic rules on the road.
Only by learning traffic principles can we flexibly complete various complex social scenarios such as braking, parking, turn signals, and lane changes. Similarly, through the study of software design principles, one can flexibly design abstract, aggregation, -coupled , and robust codes to meet various business scenarios.
If you can sum it up in one sentence: writes elegant, robust, and runnable programs!
So when learning design principles and coding, we should think more about: Is this writing elegant enough? Is it robust enough to write this way? If the answer is yes, it is already the best design. What are the design principles of
software?
Five basic principles of object-oriented design
In 2009, a buddy named Robert C. Martin proposed the concept of SOLID at a conference, namely:
Single responsibility principle (Single responsibility principle, SRP),
opening and closing The Open/Closed Principle (OCP) ,
Liskov Substitution principle (Liskov Substitution principle),
interface isolation principle (Interface-segregation principles, ISP),
dependency inversion principle (Dependency inversion principle, DIP).
Note that this guy only proposed the concept of SOLID, not the 5 principles he created. These principles existed before, and he integrated them. Just like , Jobs and just integrated mobile phones, MP3s and cameras to make the IPhone, rather than Jobs creating smartphones.
Let me mention Robert C. Martin more here. This guy is a world-class software development master, design pattern and agile development pioneer. In 2010, he published the book "How to Clean Code and ". Once this book was published, it caused an uproar in the software development industry. The editor recently re-read it, and it is so commendable that the standards from 12 years ago are still applicable in the computer world and are not clichéd.
Let’s take a look at the books published by this guy. The ratings on Douban are:
. You can see that the ratings of the books he published are quite high, which is enough to show his extraordinary strength!
Single responsibility principle (Single responsibility principle, SRP)
This principle was given by Mr. Martin in his book "Agile Software Development, Principles, Patterns and Practices". But it is also built on the shoulders of giants. To put it bluntly, it is what we software engineers often say: high cohesion! The most abstract thing here is what is responsibility? Mr. Martin's definition is "a cause for change."
Example:
You can imagine that we create a report in real life. We changed it for two reasons:
, the report content can be edited, such as modification, formatting and other functions2, the report format can be changed, such as converting to PDF, printing and other functions
The single function principle believes that the problems in these two aspects are actually are two separate functions. In this way, when we design, we should design into two different classes or modules, so that each class or module has only one function.
What are the benefits of doing this?
imagine if not separated. We have modified the content of the report. Are we worried that the printing function may not work? Similarly, if we print a report, will we worry that the content of the report is incorrect? Obviously not, that's because our editorial department affects printing, and our printing does not affect editing, which can make the software more robust.
The Open/Closed Principle (OCP)
This principle is Bertrand Meyer was given in his "Object-Oriented Software Construction" published in 1988. Mr. Martin's 1996 article "The Opening and Closing Principle" is a heuristic work using this method. The core of this principle is: Once
is completed, except for modifications in the case of errors, new functions will be completed through expansion.
simply means:
is open for expansion but closed for modification.
Example:
We want to send a notification. For example, now that there is an email notification, now we need to add a phone notification. If we modify the original notification, we may affect the previous email notification, which brings risks. Therefore, we do not modify the original notification, but expand new notification methods. If necessary, we can call the new notification method. This avoids the risks of the original business.
But how can we connect to new notifications? This requires a high level of abstraction ability. For example, an email notification requires an email address, and a phone notification requires a phone number. Even the form and content of the notification are different. If the upper layer is well abstracted and the notification sending logic is implemented separately, it can achieve a very elegant and comfortable performance. Just like whether we are taking a train or a plane, we only need people to go there and take it.
Liskov Substitution principle (Liskov Substitution principle)
It was first proposed by Barbara Liskov (Barbara Liskov) in a speech titled "Abstraction and Hierarchy of Data" at a conference in 1987. So it is named Liskov Substitution principle.
The so-called Richter substitution, in essence, concrete can replace abstraction. The son has all the abilities of the father (the son can spend the father's money).
Example:
A factory recruits workers, then both male and female workers can participate; if a factory recruits female workers, then male workers cannot participate, but female workers can participate; if a factory recruits young female workers, then at this time Older female workers are not allowed to participate, etc.
So why is it designed like this? This involves another characteristic that computer software needs to comply with: robustness! In actual projects, each subclass corresponds to different business meanings, using the parent class as a parameter to pass different subclasses to complete different business logic.
Interface-segregation principles (ISP)
Each of us likes simplicity. Give me what I need and take away what I don’t need. The same is true in the world of programming. What if we achieve this simplicity? Interface isolation is required.
Example:
I just want to walk, just give me a pair of shoes; I want to ride a bike, just give me a bicycle. If I want to walk and ride a bike, give me a pair of shoes and a bike.
In this way, we have achieved it. We don’t need to pay attention to what we don’t want, thus achieving an isolation effect. This allows to decouple between software.
The purpose of the Interface Separation Principle (ISP) is to decouple systems so that they can be easily refactored, changed, and deployed.
dependency inversion principle (Dependency inversion principle, DIP)
The dependency inversion principle was proposed by Robert C. Martin and was stated in several public works, including the paper "Quality Standards for Object-Oriented Design: An Analysis of Dependencies" and an article that appeared in C++ in 1996 The article in the report is titled "Dependency Inversion Principle", and two books are "Agile Software Development, Principles, Patterns and Practices" and "Agile Principles, Patterns and Practices in C#".
Example: The father needs to rely on a certain ability of his son, but theoretically the father cannot directly dispatch the son (for example: the son is not born yet or the son is underage), then the father can abstract this ability and wait until the son grows up. Let’s implement this abstraction concretely. This is called dependency inversion.
This principle stipulates:
High-level modules should not depend on low-level modules, and both should depend on abstract interfaces. Abstract interfaces should not depend on concrete implementations. The specific implementation should depend on the abstract interface.
Other design principles
Law of Demeter (LoD)
Law of Demeter (LoD) is also known as " Principle of Least Knowledge (Principle of Least) Knowledge). The name of this principle comes from the Greek mythological goddess of agriculture, Demeter the Lonely. The principle was invented at Northeastern University in the United States in late 1987 and can be summarized simply in any of the following ways:
h Each unit of tml1 can only have limited knowledge about other units:is only a unit closely related to the current unit; each unit can only talk to its friends:
cannot talk to unfamiliar units;
can only talk to its direct friends. chat.
In short, if we use modern words: professional people do professional things and concentrate on doing big things!
Example:
A person can command a dog to walk, but he should not directly command the dog’s legs to walk. The dog should command and control it. of How legs walk.
Demeter's law makes software more maintainable and adaptable. Because objects are less dependent on the internal structure of other objects, the object's own implementation can be changed without changing its caller.
Don't repeat yourself. (Don't repeat yourself, DRY)
The principle of DRY (dry) is that "every part of the system must have a single, clear, and authoritative representative." Its counterexample is WET (wet), which has a variety of full names, including ". "Write everything twice", "We enjoy typing" or "Waste everyone's time" (a waste of everyone’s time).
Example:
For example, if people walk with legs, if we have multiple places that say people walk with legs, if suddenly people evolve, they can also walk with hands. At this time, Many changes are needed to achieve this. Increased workload and uncontrollable factors.
But sometimes for the sake of readability, or to avoid coupling, or premature refactoring, or development efficiency, the DRY principle should be abandoned as a norm or a guide. . Real-life scenarios do not necessarily require the use of design principles. Just like writing a five-character poem , being able to write refreshing and breathtaking poems without adhering to principles is worthy of admiration.
Conclusion
In addition to the principles mentioned above, there are many principles, such as:
KISS principle (Keep It Simple, Stupid): Its essence is to pursue simplicity and ease of maintenance, similar to the single responsibility principle.
YAGNI Principle (You Ain’t Gonna Need It): programmers should only implement corresponding functions when facing solid needs, with the intention of not over-designing.The principles of
may be diverse, but they have only one purpose: to write high-quality code!
In actual work, do not be superstitious about principles. After all, principles are also to make work easier. If blind superstition becomes a burden, it will put the cart before the horse and the gain will outweigh the loss.
