Five Principles of OO: Solid

Interestingly, the Five Principles of OO can be abbreviated as one word:Solid(Stability and stability) In fact, an organization should be stable. If it is not internally united (cohesion), how can it be stable! If cohesion is not high, the internal revolution will happen when there is a new change!

How to explain solid? It is actually the first letter of the five words:

 

1.S:Single Responsibility Principle (SRP) single Responsibility PrincipleThat is to say: the class should have a single responsibility, And do not worry about it.

2.O:Open & close principle (OCP) Principle, That is, whether you design the class reasonably when designing a system. The standard of detection is whether you write new code to meet new requirements, rather than modify the original code. Of course, things may not be so absolute, but at least we need to work in this direction:Disable Modification(Try not to make changes affect the classes that have already been designed ),Open to scaling(The new logic can be implemented by adding new code ).

3.L:Liskov substitution principle (LSP)'s replacement principle, That is, any parent class can be used to assign a value to the reference of the parent class, for example:

1 class ParentClass{}2 class SubClass : ParentClass{}3 ParentClass pc = new SubClass();

This is a bit one-sided to understand, but the actual programming process is basically like this to process the Code; in fact, it also embodies a principle: Using abstraction to encapsulate changes, here, parentclass can be understood as an abstract class (abstract class parentclass) to encapsulate the changes of sub-classes. It does not depend on the specific implementation of sub-classes, nor does it need to relate to the number of sub-classes.

4.I:Interface segregation principle (ISP) interface separation principleThat is, it is better to use multiple APIs related to specific logic than to use one interface that covers all business methods. This can also be understood from the perspective of a single responsibility. When the business combination relationship is complex and changing, the combination of multiple single-responsibility interfaces makes the code structure clearer and easier to maintain and expand.

5.D:Dependence inversion principle (DIP) Dependency inversion principle, That is, it depends on abstraction. Do not rely on specifics. At the abstraction level, there should be no dependency on details. The advantage of doing so is that it can cope with possible changes to the maximum extent.

 

Each principle is related to each other. In code design, it is necessary to use it flexibly and constantly refactor it to weaken the impact of the system on changes!