Object-oriented Programming 3 major features 7 principles

One, object-oriented characteristics

Three basic features: encapsulation, inheritance, and polymorphism. 1, packaging
The core idea of object-oriented programming this is to encapsulate the data with the operations of the data. By abstraction, that is, extracting common properties from concrete instances to form general concepts, such as class concepts. 2. Inherit
Inheritance embodies an advanced programming pattern. Subclasses can inherit the properties and functionality of the parent class, which inherits the data and the data from the parent class, while adding operations on the data and data unique to the subclass. For example, "Human" inherits the attributes and functions of "mammals", At the same time, the addition of human unique properties and functions. 3, polymorphism
Polymorphism is another important feature of object-oriented programming. There are two meanings of polymorphism (manifested as method overrides (overriding) and overloads (overloading))
One is the polymorphism of the operation name, where multiple operations have the same name, but the types of messages received by these operations must be different. The so-called operation name polymorphism means that you can pass different messages to the operation so that the object produces a certain behavior according to the corresponding message.
Two or seven large basic principles
7 Cardinal principles: the principle of sole responsibility SRP (single responsibility Princ iple), the open closure principle OCP (Open-close principle), the principle of substitution, the principle of dependency (the Dependency Inversion principle DIP) (the Liskov substitution principle LSP), the interface separation principle (the Interface segregation principle ISP), the "Dimitri" rule , Combinatorial/Aggregation principles

1. The principle of sole responsibility SRP (single responsibility principle)
That a class is responsible for only one responsibility
Can reduce the complexity of the class, a class is responsible for only one responsibility, its logic is certainly more than responsible for many responsibilities simple;
Improve the readability of the class and improve the maintainability of the system;
Changes caused by risk reduction, change is inevitable, if the single responsibility principle is good, when modifying a function, can significantly reduce the impact on other functions.
One point to note is that the principle of single responsibility is not only specific to object-oriented programming ideas, but a single responsibility principle is applied to modular programming.

2, open closure principle OCP (Open-close principle)
A module should be open in terms of extensibility and should be closed in terms of modification. For example: A network module, the original server only function, and now to join the client function,
Then, without modifying the service-side function code, it is possible to increase the implementation code of the client function, which requires that at the beginning of the design, the server and the client should be separated and the public part abstracted out.

3, the Richter replacement principle (the Liskov substitution principle LSP)
Subclasses should be able to replace the parent class and appear anywhere the parent class can appear.

4, relying on the reverse principle (the Dependency inversion principle DIP)
Depending on the abstraction, the upper layer relies on the lower layer. Suppose B is a lower module than a, but B needs to use the function of a,
At this point, B should not directly use the specific classes in a: Instead, it should define an abstract interface by B and implement the abstract interface by a, b using only this abstract interface: this will achieve
The purpose of dependency inversion, B also relieves dependency on a, which in turn is dependent on the abstract interface defined by B. It is difficult to avoid relying on the lower modules through the upper module, if B also directly depends on the implementation of a, then can cause circular dependency. A common problem is that when compiling a module, you need to include a CPP file directly to the B module, while compiling B is also included directly in a CPP file.

5, the interface separation principle (the Interface segregation principle ISP)
The modules are separated by an abstract interface, rather than by a specific class strong coupling. Interface-Oriented Programming

6. The law of "Dimitri"
Also called the minimum knowledge principle, that is, an object should have as little understanding of other objects as possible
① on the Division of class, we should create a class with weakly coupling;
② in class structure design, each class should minimize the access rights of members;
③ in the design of classes, whenever possible, a class should be designed as invariant classes;
④ on references to other classes, an object's reference to other objects should be minimized;
⑤ as far as possible to reduce class access rights;
⑥ use serialization functions cautiously;
⑦ do not expose class members, but should provide the appropriate accessors (properties).

7. Combinatorial/Aggregation Principles
Also called the principle of synthetic reuse. The principle is to use some existing objects within a new object, including combinatorial relationships and aggregation relationships, to become part of the new object, by delegating the method of invoking an existing object to reuse its existing function. That is, try to use the composite reuse of the class, and try not to use inheritance.

is to use some existing objects within a new object to become part of the new object, and the new object is used to reuse the existing functionality by delegating to those objects. This principle has a short description: Try to use compositing, aggregation, and try not to use inheritance.

1 The only way for a new object to access the Component object is through the interface of the Component object

2 This reuse is a black box reuse, because the internal details of the component objects are not visible to the new object

3 This reuse can be performed dynamically during the running time, and the new object can dynamically refer to objects of the same type as the Component object

4 synthesis, aggregation can be applied to any environment, and inheritance can only be applied to some limited environment

5 A common cause of the use of synthesis, aggregation, and inheritance for errors is the mistaken "has-a" relationship as "is-a". If two classes are "Has-a", then use compositing, aggregation, and if it's a "is-a" relationship, you can use inheritance

In object-oriented design, there are two basic ways to reuse existing designs and implementations in different environments, that is, by combining/aggregating relationships or by inheriting.

1 Inheritance reuse: Simple to implement, easy to expand. Damage to the encapsulation of the system, the implementation from the base class is static, it is not possible to change at runtime, not enough flexibility, can only be used in a limited environment. ("White box" reuse)

2 combination/Aggregation multiplexing: Relatively low coupling, selective invocation of the operation of the member object, can be dynamic at run time. ("black box" reuse)

The combination/aggregation can make the system more flexible, the coupling between class and class is reduced, the change of one class has relatively little impact on other classes, so it is generally preferred to use combination/aggregation for reuse, second, to consider inheritance, in the use of inheritance, the need to strictly follow the principle of the Richter substitution, the effective use of inheritance will help to understand the problem , reducing complexity, while abusing inheritance will increase the difficulty of system construction and maintenance as well as the complexity of the system, so it is prudent to use inheritance reuse.