The five design principles of SOLID are often referred to as:
S = Single Responsibility Principle
O = Opened Closed Principle
L = Liscov Substitution Principle
I = Interface Segregation Principle
D = Dependency Inversion Principle
details as follows:
1. Single Responsibility Principle
There should never be more than one factor that causes a class to change, or in other words: a class has one and only one responsibility.
If a class contains multiple responsibilities, the code becomes coupled; SRP seems to separate things into sub-parts so that they can be reused and managed centrally, and the same applies at the method level.
2. The principle of open and closed
Software entities (classes, modules, functions, etc.) should be open for extension and closed for modification.
(About externally associated interfaces or abstract classes)
3. Liskov's substitution principle
Subtypes must be able to replace their base types, or functions that use base class references must be able to use objects of inherited classes without having to know about it.
Why LSP is so important:
I. If there is no LSP, the class inheritance will be messed up; if the subclass is passed as a parameter to the method, there will be unknown behavior;
II. If there is no LSP, unit tests applicable to the base class cannot be successfully used to test the subclass;
4. Interface separation principle
Clients should not be forced to depend on interfaces they do not use; interfaces should contain only the necessary methods and nothing else.
for example:
Notice that the IBird interface contains a lot of bird behavior, including the fly() behavior. Now if a Bird class (like an Ostrich ostrich) implements this interface, then it needs to implement the fly() behavior unnecessarily (Ostrich doesn't fly). This "fat interface" should be split into two different interfaces, IBird and IFlyingBird, IFlyingBird inherits from IBird. Here, if a bird cannot fly (such as Ostrich), it implements the IBird interface. If a bird can fly (eg Sparrow), then it implements IFlyingBird.
5. Dependency Inversion Principle
High-level modules should not depend on low-level modules, both should depend on their abstractions.
For example, a car class, which should depend on the interface, must be written as IEngine eg; :
class Car{
ChinaEnginee eg; // wrong here
}
If we don't use dependency inversion in our code, we will face the following risks:
I. Using low-level classes will break high-level code;
II. It takes a lot of time and cost to modify the high-level code when the low-level class changes;
III. Generate low reuse code;
In addition to the five principles of SOLID, there are other object-oriented principles.
E.g:
Composition instead of inheritance: Compared with inheritance, it is more inclined to use composition;
Demeter's Law: The less your class knows about other classes, the better;
Common closure principle: related classes should be packaged together;
The principle of stable abstraction: the more stable a class is, the more abstract classes it should be composed of;