Six basic principles of object-oriented design

Six basic principles of object-oriented design:
1) Open and closed principle
2) Liskov substitution principle
3) Dependency inversion principle
4) Interface isolation principle
5) Demeter's principle
6) Synthesis/aggregation reuse principle Explain the six basic principles

in turn Principles:
1) Open-closed principle:
    open for extension and closed for modification, that is, the system supports extension but not modification.
    Why do this?
In the development stage, we all know that if we extend a function, if we just blindly modify the method, it may cause some problems, such as new bugs may be introduced, or the complexity of the code may be increased, and the code structure may be damaged. , redundancy, and full re-testing is required. So how to solve these problems? Very simple, this requires the system to support expansion. Only a system with good scalability can introduce new functions without modifying the existing implementation code.

    What should we do?
To achieve the open-closed principle, it is necessary to use more abstract classes or interfaces, abstract similar classes, and introduce public functions into abstract classes, so that when extending, only new subclasses need to be generated based on abstract classes. That's it.

2) Liskov Substitution Principle:
    That is, wherever a base class is used, subclass substitution can be used, and after subclass substitution, the system can work normally.
    Why do this?
Using the Liskov substitution principle can enhance the robustness of the program, and maintain very good compatibility when the version is upgraded. Even if subclasses are added, the original subclasses can continue to run.
    What should we do?
Where you refer to the base class, you can refer to the subclass to implement


3) Dependency inversion principle:
    That is, our client class should depend on abstraction, not on concreteness, which is what we often hear as "interface-oriented programming".
    Why do this?
Reduce the coupling between classes and improve the readability and maintainability of the code.
    What should we do?
a. Each class should have interfaces and abstract classes as much as possible, or both abstract classes and interfaces.
b. The surface type of the variable should be an interface or an abstract class as much as possible.
c. No class should be derived from a concrete class. (But when doing secondary development, the exception is when we can't get high-level code), the rules are not absolute.
d. Try not to override the methods already implemented in the base class.

4) The principle of interface isolation:
     that is, the granularity of the interface should be minimized, the functions should be divided into each sub-role that can no longer be divided, and an interface should be created for each sub-role. In this way, the implementation class of the interface will not implement some unnecessary functions. function.
    Why do this?     What should we do to
avoid making the implementation class of the interface implement some unnecessary functions ? Establish a single interface, do not establish a bloated and huge interface, that is to say, the method of the interface is as few as possible. 5) Law of Demeter:     Minimize dependencies between classes.     Why do this?        Reduce coupling between classes.     What should we do?        The most direct implementation in the application is to build an intermediary class between the two classes. But this may cause the explosion of intermediaries. 6) The principle of synthesis/aggregation reuse:     that is, use less inheritance and more combination.












    Why do this?
Preferring composition/aggregation of objects will help you keep each class encapsulated and focused on a single task. This way classes and class inheritance hierarchies stay small and less likely to grow into uncontrollable behemoths.
    What should we do?
Using composition is to establish an association relationship between two classes, and use one class as an attribute of another class.
Inheritance and composition are mainly to distinguish whether the relationship between two roles is "is a" or "has a", if it is "is a", you need to use inheritance, and if it is "has a", you need to use composition.
For example, pens can be divided into fountain pens and oil pens, which is the relationship of is a, but the relationship between oil pens and refills is has a.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326995734&siteId=291194637