Basic Principles of Object-Oriented Programming

A long time ago, I knew that object-oriented design had some well-recognized basic principles, but they were all part of a fragmented understanding. Although they were consciously used in the process of practice, but I have never summarized it systematically. This is a detailed introduction I have found on the Internet. Just take a reading note.

All design patterns are encapsulated for different variability, so that the system meets the requirements of the "Open and Close principle" from different angles.
　　
In a software system, the most important and important sign of a module's poor design is the extent to which the module hides its internal data and other implementation-related details. A well-designed module can hide all its implementation details and completely separate the APIS provided to the outside world from its own implementations. In this way, the module and the module can communicate with each other only through each other's APIs, regardless of the internal work details of the module.
　　
　　
The fundamental guiding principle of OO design is to improve maintainability and reusability. These principles mainly include:
　　1. Open and Close principles
A software entity should be open to extensions and closed to modifications.
When designing a module, this module can be expanded without being modified. In other words, you can change the behavior of this module without having to modify the source code.
　　
How can we achieve neither modification nor expansion?
The key to solving the problem lies in abstraction: in the C # language, one or more abstract C # classes or C # interfaces can be provided, define the method features required by all specific classes as the abstraction layer of system design. This abstraction layer predicts all possible extensions, so it will not change in any expansion case. In this way, the abstraction layer of the system does not need to be modified, and thus the modification is disabled.
At the same time, because exporting one or more new classes from the abstraction layer can change the behavior of the system, the system design is open to expansion.
　　
The open/closed principle is actually a "closed principle of variability": Find a variable factor in the system and encapsulate it. This principle involves two points:
1) A variability should not be scattered in many corners of the code, but should be encapsulated into an object. The different representations of the same variability mean the specific sub-classes in the same hierarchy.
Inheritance is regarded as a method to encapsulate changes, rather than being considered as a method to generate special objects from general objects.
2) One variability should not be mixed with another. (The inheritance structure of all class diagrams generally does not exceed two layers. Otherwise, two different variability will be mixed together .)
　　
The principle of opening and closing is the general principle, while the other several are the means and tools of the principle.
　　
　　2. Principle of dependency reversal
The principle of dependency inversion is: to rely on abstraction, not to rely on implementation.
The principle of opening and closing is the goal, and the means to achieve this goal is dependent on the reversal principle.
Abstract layers include the business logic of the application system and macro strategic decisions that are important to the entire system. They are the embodiment of inevitability; the specific layers contain secondary Implementation-Related Algorithms and logic, as well as tactical decisions, with a considerable chance to choose. Code at a specific level is subject to frequent changes and errors cannot be avoided.
Abstract layers contain the most important macro-business logic of an application system, which is the place for Strategic judgment and decision. Abstract layers should be relatively stable and should be the focus of reuse; it should also be the focus of maintenance.
In many cases, a C # program needs to reference an object. At this time, if the object has an abstract type, the abstract type should be used as the static type of the variable. This is the meaning of interface programming.
Generally, when creating an object, the C # language requires the use of the new keyword and the class itself. Once this object has been created, you can use the abstract class type of this object to reference it flexibly. For example, DbConnection conn = new SqlConnection (); therefore, the process of creating an object in C # violates the "open/closed principle" and the dependency reversal principle (because Mr has become a specific type, using abstract references), although after this class is created, the client can rely on its abstract type through polymorphism. Because of this problem, the design mode provides multiple creation modes, especially several factory models, which are used to solve the Dependency inversion problem during object creation.
Factory mode encapsulates the process of creating a class instance. The client that consumes the instance only obtains the instantiation result and the abstract type of the instance. Of course, no method can avoid the new Keyword required by the C # language and the method of directly calling the constructor of a specific class (this violates the Rys replacement principle ). The simple factory model encapsulates this violation of the "Opening and Closing principle" and the dependency reversal principle into a class, and the factory method model delays this violation to a specific factory role. Through proper encapsulation, the factory model can purify most of the structures and isolate the practices that violate the principles into easy control.
　　
Joint use of C # interface and C # Abstract class: The Declaration type is undertaken by the C # interface, but a C # Abstract class is also provided, which provides a default implementation for this interface. If a specific class directly implements this C # interface, it must implement all its own interfaces. On the contrary, if it inherits from an abstract class, it can save unnecessary methods, because it can automatically obtain the default implementation of these methods from the abstract class. This is actually the default adaptation mode.
　　
　　Disadvantages of dependency inversion:
1) because of dependency inversion, object creation is likely to use the object factory to avoid direct reference to specific classes. The use of this principle will also lead to a large number of classes. For engineers who are not familiar with object-oriented technology, maintaining such a system requires good object-oriented design knowledge.
2) The dependency reversal principle assumes that all specific classes will change, which is not always correct. Some specific classes may be quite stable and will not change. The client that consumes this specific class instance can depend on this specific type completely without having to create an abstract type for this.
　　
　　3. Lee's replacement principle
Where any base class can appear, subclass can certainly appear.
The key step of the open and closed principles is abstraction. The inheritance relationship between the base class and sub-classes is the specific embodiment of abstraction, And the rith replacement principle is the standard for the specific steps to achieve abstraction.
　　
　　4. Principles of synthesis/aggregation multiplexing
We recommend that you use synthesis/aggregation as much as possible, instead of inheritance relationships for reuse.
The synthesis/aggregation principle requires that we first consider the synthesis/aggregation relationship. The Rys replacement principle requires that, when using inheritance, we must determine that this inheritance relationship meets certain conditions (inheritance is used to encapsulate changes; where any base class can appear, subclass can certainly appear .)
　　
The synthesis/aggregation principle is to use some existing objects in a new object to make it part of the new object; new objects can reuse existing functions by assigning them.
　　
　　5. dumit principles
A software entity should interact with as few other entities as possible. There is little interaction between modules. The result is that when the system functions need to be extended, it is easier to close the changes.
An object should have as little understanding as possible about other objects.
　　
　　Specific actions of the dimit principle:
1) set a class to a non-changing class first. Unchanged classes are easy to design, implement, and use. For example, the String class in C # API.
Communication between an object and the outside world is generally divided into two types: one is to change the state of this object, and the other is not to change the state of this object. If the internal state of an object cannot be changed at all, the communication between the object and the outside world will be greatly reduced.
When any class is involved, first consider whether the status of the class needs to be changed. Even if a class must be a mutable class, you must keep a mean attitude when assigning values to its attributes. Do not set a value Assignment Method for an attribute unless necessary.
　　
2) Minimize the access permissions of a class.
3) Use Serializable with caution. Once a class is set to Serializable, the internal structure of the class cannot be modified in the new version, including the private method and period.
4) Minimize the access permissions of members.
　　
　　6. Interface isolation principles
The client should be provided with an independent interface as small as possible, rather than a large total interface. That is, it is better to use multiple special interfaces than to use a single total interface.
Both the interface isolation principle and Demeter restrict the communication between a software entity and other software entities. The DEMETER principle requires that the width and depth of the communication be limited as much as possible, and the product isolation principle requires that the width of the communication be as narrow as possible. As a result, a software system does not transfer the modification pressure to other objects during function expansion.
　　
An interface is equivalent to a role in the script, and the actors playing this role on a stage are equivalent to the implementation of the interface. Therefore, an interface should represent a role rather than multiple roles. If the system involves multiple roles, each role should be represented by a specific interface.
　　
Custom Service: if the client only needs some methods, it should provide these required methods to the client, rather than the unnecessary methods. (It is a commitment to provide public interfaces to clients. There is no need to make unnecessary commitments. Too many commitments will cause unnecessary burden on system maintenance .)