Review of Object-Oriented Design Principles

I went home yesterday. By the way, I brought back a lot of webcast and stayed in bed for an afternoon. Because there are a lot of design patterns in the Enterprise Library, I listened to Microsoft's lecturers for an afternoon.

Alas! The quality of webcast is really junk.

When I heard it, I found out that I suddenly couldn't think of the four principles of object-oriented, so I had to hurry up and learn again. Because it has been copied to the notepad (dial-up surfing the internet at home ......), So I forgot the original article address. I would like to express my gratitude to the author here.

The cornerstone of object-oriented design is the "open-close" principle.
The principle of "Opening and Closing" is that a software entity should be open to extensions and closed to modifications.
This rule means that when designing a module, the module should be extended without being modified.
From another perspective, this is the so-called "encapsulation principle of variability ". "Encapsulation principles for variability" means two points:
1. A variability should not be scattered in many corners of the code, but should be encapsulated into an object. Different representations of the same variability mean that specific sub-classes in the same hierarchy are inherited.
2. One variability should not be mixed with another. That is, the inheritance structure of the class graph should not exceed two layers.
It is not easy to implement the "open-close" principle, but there are also many rules to follow. These rules are also design principles, and they are tools to implement the "open-close" principle.

Rishi replacement principle
Rishi replacement principle: if there is an object O2 of Type T2 for every object O1 of Type T1, so that all program P defined by T1 can be changed to O2 for all objects O1, if the behavior of program P is not changed, Type T2 is the child type of T1.
That is, if a software entity uses a base class, it must also be applicable to child classes. However, the alternative is not valid.
If the relationship between two specific classes A and B violates the Li's replacement principle, you can choose one of the following two reconstruction schemes:
1. Create a New abstract class C. As the superclasses of the two classes, move the behavior of A and B to C to solve the inconsistency between A and B.
2. the inheritance relationship from B to a is rewritten as a delegate relationship.

Dependency reversal Principle
The principle of dependency inversion is: to rely on abstraction, not on specifics. That is, do not implement programming for the interface. Interface Programming means that you should use interfaces and abstract classes to declare the types of variables, declare the types of parameters, declare the return types of methods, and convert data types. Do not implement programming. That is to say, you should not use a specific class to declare the type of the variable, the type declaration of the parameter, the return type declaration of the method, and the conversion of the data type.
The dependency inversion principle is powerful but not easy to implement. Because of dependency inversion, object creation is likely to use an object factory to avoid direct reference to a specific class, the use of this principle will also lead to a large number of classes. Maintaining such a system requires good object-oriented design knowledge.
In addition, the dependency reversal principle assumes that all specific classes are changed, which is not always correct. Some specific classes may be quite stable and will not change. Clients that consume this specific class instance can depend on this specific class completely.

Interface isolation principle
The principle of interface isolation is that it is better to use multiple special interfaces than to use a single interface. From the customer's point of view, the dependence of a class on another class should be based on the smallest interface. If the client only needs some methods, it should provide the client with the required methods, rather than the unnecessary methods. The provision of interfaces means to make a commitment to the client. Excessive commitment will cause unnecessary burden on system maintenance.

Principles of synthesis and aggregation Reuse
The principle of merging and aggregation reuse is to use some existing objects in a new object to make it a part of the new object, new objects reuse existing functions by assigning them. There is a brief description of this principle: we should try to use synthesis and aggregation, and try not to use inheritance.
Synthesis and aggregation have the following benefits:
The only way for a new object to access a component object is through the component object interface.
This reuse is black box reuse, because the internal details of the component object are invisible to the new object.
This type of reuse can be performed dynamically during the running time. New objects can dynamically reference objects of the same type as component objects.
Synthesis and aggregation can be applied to any environment, but inheritance can only be applied to some limited environments.
One common cause of incorrect use of synthesis, aggregation, and inheritance Is that the "Has-a" relationship Is treated as the "Is-a" relationship. If the two classes are "Has-a" relationships, synthesis and aggregation should be used. If they are "Is-a" relationships, inheritance can be used.

Dimit Law
The dimit rule says that an object should have as little knowledge as possible about other objects. That is, it only communicates with your direct friends and does not talk to strangers. If you need to talk to strangers, and your friends and strangers are friends, you can forward your calls to strangers by your friends so that they only know friends and strangers. In other words, a person will think that he is calling a friend's method.
The following conditions are called friend conditions:
The current object.
Input the object to the current object method as a parameter.
The instance variable of the current object directly references the object.
If the instance variable of the current object is an aggregation, the elements in the aggregation will also be friends.
The object created by the current object.
If any of the above conditions is met, it is the friend of the current object. Otherwise, it is a stranger.
The primary purpose of the dummit rule is to control information overload. When applying it to system design, pay attention to the following points:
In terms of classification of classes, classes with weak coupling should be created. The weaker the coupling between classes, the more conducive it is to reuse.
In the structure design of classes, each class should minimize the access permissions of members. A class should not have its own public attributes. Instead, it should provide a method of value and value assignment to allow the outside world to indirectly access its own attributes.
As long as possible, a class should be designed to be a constant class.
When referencing other objects, the reference of a class to other objects should be minimized.