Some principles of class design in object-oriented programming

1. Opening and closing principle (the Open Closed principle OCP)

A module should be open in terms of extensibility and should be closed in terms of modification. Therefore, the interface encapsulation mechanism, abstract mechanism and polymorphic technique should be considered as far as possible in object-oriented design. The principle is also suitable for non object-oriented design method, is one of the important principles of software engineering design method. We take the example of the radio as an example to tell the principle of object-oriented opening and closing. When we listen to the program, we need to turn on the radio, focus on the radio frequency and adjust the volume. But for different radios, the details of the three steps are often different. For example, the automatic contraction of radio and button-type contraction in the operating details are not the same. Therefore, it is not possible for each of the different types of radios to implement these different modes of operation through a radio class (via overloading). But we can define a radio interface that provides six abstract methods for powering up, shutting down, increasing frequency, reducing frequency, increasing volume, and lowering volume. Different radios to inherit and implement these six abstract methods. This new type of radio will not affect other original radio types, radio type expansion is extremely convenient. In addition, the existing radio type does not affect other types of radios when modifying its method of operation.

2. Principle of substitution (the Liskov substitution principle LSP)

Subclasses should be able to replace the parent class and appear anywhere the parent class can appear. This principle is the design principle that Liskov put forward in 1987. It can also be introduced from the concept of Bertrand Meyer's DBC (design by Contract).

We take the student as an example, evening school is student's subclass, so in any place where the student can appear, evening school students can appear. This example is somewhat far-fetched, an example that can reflect this principle and an ellipse, and a circle is a special subclass of the ellipse. So any place where the ellipse appears, the circle can appear. But it may not work in the opposite way.

When applying the substitution principle, we try to design Class B as an abstract class or interface, let the C class inherit Class B (interface B) and implement operation A and Operation B, at runtime, the class C instance replaces B so that we can extend the new class (inheriting Class B or interface B) without modifying Class A.

3. The principle of dependence (the Dependency inversion principle DIP)

In business design, dependencies related to a particular business should rely on interfaces and abstract classes as much as possible, rather than on specific classes. Specific classes are only responsible for the implementation of the relevant business, modify the specific classes do not affect the specific business-related dependencies.

In the structural design, we can see that the underlying module is the implementation of high-level abstract module (high-level abstract module by calling the underlying module), this shows that the abstract module to rely on the specific implementation of the relevant modules, the implementation of the underlying module changes will seriously affect the high-level abstraction of the module, obviously this is a structured approach to a " Mishap. "

The dependencies of object-oriented methods are just the opposite, and the concrete implementation classes rely on abstract classes and interfaces.

For this reason, when we do business design, we should try to define the prototype of the business method in the interface or abstract class, and implement the business method through the concrete implementation class (subclass), the modification of the content of the business method will not affect the call of the runtime business method.

4. Interface separation principle (the Interface segregation principle ISP)

Using multiple interfaces related to a particular customer class is preferable to adopting a generic interface that covers multiple business methods.

The ISP principle is another enabling technology that supports components such as COM. The availability and portability of components and classes will be compromised by the lack of ISPs.

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 the client class inherit multiple specific business interfaces will be more efficient than all the methods required to load the customer directly.

The above four principles are the principles that are often used in object-oriented objects. In addition, in addition to the above four principles, there are some commonly used experience, such as the class structure level of three to four layers advisable, the role of the class of clear (a class corresponding to a specific responsibility), etc., we are in the object-oriented design reference. However, in view of the above principles, we can see that these classes show the relationship of tree topology on the geometrical distribution, which is a good, open linear relationship with lower design complexity. Generally speaking, in software design we should try to avoid the design relationship with closures and loops, they reflect the greater coupling degree and the complexity of design.