Single Responsibility Principle
Single Responsibility Principle (SRP), which means that there should be a single function. The precise explanation is that for a class, there should be only one reason for it to change.
If a class has too many responsibilities, it is equivalent to coupling these responsibilities together, and a change in one responsibility may weaken or inhibit the ability of the class to complete other responsibilities.
This coupling can lead to fragile designs that suffer unexpected disruptions when changes occur.
This coupling can lead to fragile designs that suffer unexpected disruptions when changes occur.
Much of what software design really does is discovering responsibilities and separating those responsibilities from each other.
If you can think of more than one motivation to change a class, then the class has more than one responsibility.
open-closed principle
In the software design pattern, this kind of idea that cannot be modified, but can be extended is also the most important design principle, which is the
Open-Closed Principle (The Open-Closed Principle, OCP for short) or the Open-Closed Principle.
The open-closed principle states that software entities (classes, modules, functions, etc.) should be extensible, but not modifiable.
This principle actually has two characteristics, one is to say 'Open for extension', the
other is to say 'closed for modification'
When we are working on any system, we should not expect that the system needs to be determined at the beginning, and it will never change again. This is an unrealistic and scientific idea.
Since the demand will definitely change, how to face the demand When changes are made, the designed software can be modified relatively easily, not to say that when
new requirements come, the entire program must be pushed over again. What kind of design can remain relatively stable in the face of changing requirements, so that the system
can continuously introduce new versions after the first version? Open-Closed gives us the answer.
The open-closed principle means that when you design, you should always consider it, try to make this class good enough, and don't modify it after writing it.
If new requirements come, we add some classes and it's done. The original The code doesn't move if it doesn't move.
No matter how 'closed' a module is, there will be some changes that cannot be closed to it. Since it is not completely closed by Cohen, the
designer must make a choice as to which changes the module he designs should be closed to.
He must first guess the most likely kinds of changes, and then construct abstractions to isolate those changes.
Wait until the change happens and act now.
As the saying goes, in the same place, it is not your fault that you fall the first time, and it is your fault that you fall again here.
When we originally wrote the code, we assumed that changes would not happen. When a change occurs, we create abstractions to isolate future changes of the same kind.
In the face of demand, changes to the program are made by adding new code, not changing existing code. This is the spirit of the 'open-closed principle'
What we want is to know about possible changes soon after development begins. The longer you wait to pinpoint possible changes, the harder it is to create the correct abstraction.
The open-closed principle is at the heart of object-oriented design. Following this principle can bring the huge benefits claimed by object-oriented technology, namely maintainability, extensibility,
reusability, and flexibility. Developers should abstract those parts of the program that exhibit frequent changes; however, it is also not a good idea to
intentionally . Rejecting premature abstraction is as important as the abstraction itself.
(Going all out is of course necessary, and preparation with both hands is also a manifestation of being flexible, closed to pain and open to pleasure.)
Dependency Inversion Principle
The Dependency Inversion Principle can also be translated into the Dependency Inversion Principle. The original explanation is that abstraction should not depend on details, and details should depend on abstraction.
To put it bluntly, it is to program for the interface, not for the reality.
To put it bluntly, it is to program for the interface, not for the reality.
All things in the world follow certain similar laws, and whoever grasps these laws first will be called the strongest first.
Dependency Inversion Principle
A. High-level modules should not depend on low-level modules. Both should rely on abstraction.
B. Abstraction should not depend on details. Details should depend on abstraction.
Liskov Substitution Principle
Liskov Substitution Principle (LSP): Subtypes must be able to replace their supertypes.
If a software entity uses a parent class, it must be used in its subclass, and it does not perceive the difference between the parent class and the subclass object.
That is to say, in the software, if the parent class is replaced by its subclass, the behavior of the program does not change. Simply put, the subtypes must be able to replace their supertypes.
That is to say, in the software, if the parent class is replaced by its subclass, the behavior of the program does not change. Simply put, the subtypes must be able to replace their supertypes.
The subclass inherits the superclass, so the subclass can appear as the superclass.
If in object-oriented design, one is a bird and the other is a penguin, if the bird can fly and the penguin can't, then is the penguin a bird? Can penguins inherit from the bird class?
A penguin is a special bird, and although it cannot fly, it is also a bird.
But in object-oriented design, that means that the subclass has all the non-private behaviors and properties of the superclass. Birds can fly, but penguins can't. Although in biological classification,
penguin is a kind of bird, in the programming world, penguin cannot appear as the parent type---bird, because the premise says that all birds can fly, but penguins cannot fly, so penguins cannot Inherit the birds.
If in object-oriented design, one is a bird and the other is a penguin, if the bird can fly and the penguin can't, then is the penguin a bird? Can penguins inherit from the bird class?
A penguin is a special bird, and although it cannot fly, it is also a bird.
But in object-oriented design, that means that the subclass has all the non-private behaviors and properties of the superclass. Birds can fly, but penguins can't. Although in biological classification,
penguin is a kind of bird, in the programming world, penguin cannot appear as the parent type---bird, because the premise says that all birds can fly, but penguins cannot fly, so penguins cannot Inherit the birds.
Only when the subclass can replace the parent class and the function of the software unit is not affected, the parent class can be truly reused, and the subclass can also add new behaviors based on the parent class.
Because of the Liskov Substitution Principle, Open-Chalk became the Cohen one.
Modules that use parent types can be extended without modification due to subtype substitutability.
Dependency inversion can actually be said to be a sign of object-oriented design. It does not matter which language is used to write the program. When writing a stock, the consideration is how to program for abstraction rather than for detail programming,
that is, all dependencies in the program are terminated in Abstract class or interface, that is object-oriented design, otherwise it is procedural design.