Hello, I’m Grey Ape, a bug – writing programmer ape.

Hear the word object-oriented, we are certainly not unfamiliar, and we are usually in the development of most of the object-oriented based, but in the object-oriented programming and development, you really have in accordance with the object-oriented design principles to develop?

There are seven principles of object-oriented design, which are: single responsibility principle, open and closed principle, Lee’s substitution principle, dependence inversion principle, interface isolation principle, combination reuse principle and Demitt principle.

Let’s take a quick look at these principles. What are some of the things you don’t usually notice in your normal development?

 

(1) Single Responsibility Principle (SRP)

There should be only one reason for a class to change. That is, a class should have only one responsibility. If there are multiple responsibilities, these responsibilities are coupled together, and a change in one responsibility may impair or inhibit the ability of the class to perform other responsibilities, causing changes in the class for multiple reasons. So when constructing a class, separate the different responsibilities of the class into two or more classes (or interfaces) to ensure that there is only one cause for the class to change.

 

(2) Open and Close Principle (OCP)

Software component entities should be extensible, but not modifiable. The open-closed principle says you should try to design modules that never need to change. New code can be added to expand the behavior of the system; existing code cannot be modified. This principle achieves object – oriented encapsulation and reusability.

 

(3) Replacement Principle (LSP)

Subclasses should be able to replace the parent class and appear wherever the parent class can appear. This principle is a design principle proposed by Liskov in 1987. It can also be derived from Bertrand Meyer’s concept of DBC(Design by Contract). Take circle and ellipse for example. Circle is a special subclass of ellipse. So wherever an ellipse appears, a circle can appear.

But the reverse may not work. When applying the substitution principle, class B should be designed as an abstract class or interface as far as possible, so that class C inherits class B (interface B) and implements operation A and B. At runtime, the instance of class C replaces B, so that the extension of new class (inheriting class B or interface B) can be carried out without modifying class A.

 

(4) Dependency inversion Principle (DIP)

In business design, business-specific dependencies should rely as much on interfaces and abstract classes as possible, rather than concrete classes. A concrete class is only responsible for the implementation of the relevant business, and modifying a concrete class does not affect the dependencies associated with a particular business. In structured design, it can be seen that the underlying module is the implementation of high-level abstract module, which indicates that the abstract module depends on the module related to the concrete implementation. When the concrete implementation of the underlying module changes, it will seriously affect the high-level abstract module, which is obviously a “hard wound” of the structured method.

But object-oriented methods have the opposite dependency, with concrete implementation classes relying on abstract classes and interfaces. Therefore, in the process of business design, the prototype of business method should be defined in the interface or abstract class as far as possible, and the business method can be realized by the concrete implementation class (subclass). The modification of business method content will not affect the invocation of business method at runtime.

 

(5) Interface Separation Principle (ISP)

It is better to have multiple interfaces related to specific customer classes than to have a generic interface covering multiple business methods. The ISP principle is another enabling technology that supports componentization such as COM. The lack of AN ISP component class makes availability and portability very difficult. The essence of this principle is quite simple. If you have a class for multiple customers, creating a specific business interface for each customer and then having that customer class inherit multiple specific business interfaces is more efficient than simply loading all the methods the customer needs.

 

(6) Combination reuse principle

Where composition can be implemented, try to use composition rather than inheritance to extend functionality, because composition can achieve better encapsulation, more flexibility and more stable structure than inheritance.

 

(7) Demeter principle

The idea that one object should know the least about the other, which has the advantage of effectively reducing the coupling requirements between classes.

Do you still feel like you understand the essence of object-oriented development? If you have any questions or opinions, please leave a message in the comment section.

Feel good remember to like attention yo!

Grey ape accompany you to progress together!