I. Object-oriented Features
Three basic features: encapsulation, inheritance, and polymorphism.
1. Encapsulation
The core idea of object-oriented programming this is to encapsulate the data and the manipulation of the data. Abstract, that is, extracting common properties from specific instances to form general concepts, such as the concept of a class.
2. Inheritance
Inheritance embodies an advanced programming pattern. Subclasses can inherit the properties and functions of the parent class, that is, the subclass inherits the data and data that the parent class has, and can add the data and data that are unique to the subclass. For example, "Human" inherits the properties and functions of "mammals", At the same time, it adds the unique properties and functions of human beings.
3. polymorphic
Polymorphism is another important feature of object-oriented programming. Polymorphism with two meanings (overriding) and overloading (overloading)
One is the polymorphism of the operation name, that is, there are multiple operations with the same name, but these operations must receive different message types. The so-called Operation name Polymorphism refers to the ability to pass different messages to the operation in order for the object to produce certain behavior based on the corresponding message.
two or seven major principles
7 Basic principles: the single-duty principle SRP (unitary Responsibility Principle), the open-closure principle OCP (Open-close Principle), the principle of substitution, the principle of dependence (the Dependency Inversion Principle DIP) (The Liskov Substitution Principle LSP), Interface separation principle (the Interface segregation Principle ISP), the "Dimitri" rule , Composition/Aggregation principles
1. Single Duty principle SRP (Responsibility Principle)
That is, 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 the responsibility of more than the responsibility of more simple;
Improve the readability of the class, improve the maintainability of the system;
The risk of change is reduced, the change is inevitable, if a single responsibility principle is well adhered to, when a function is modified, it can significantly reduce the impact on other functions.
One thing that needs to be explained is that the single responsibility principle is not only specific to object-oriented programming, so long as it is a modular program design, it applies a single responsibility principle.
2. Open closure principle OCP (open-close Principle)
A module should be open in terms of extensibility and should be closed in terms of change. For example: A network module, the original service-only function, and now to join the client function,
Then, without modifying the service-side function code, you can increase the client function implementation code, which requires that at the beginning of the design, the server should be separated from the client, the public part of the abstraction.
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. Dependency reversal principle (the Dependency inversion Principle DIP)
Depending on the abstraction, the upper layer relies on the lower layer. Suppose B is a lower module, but B needs to use the function of a,
At this time, B should not directly use the specific class in a: Instead, a abstract interface should be defined by B, and a to implement this abstract interface, B only use this abstract interface: this will achieve
For the purpose of dependency inversion, B also relieves dependency on a, which in turn is an abstract interface dependent on the B definition. It is difficult to avoid relying on the lower module through the upper module, if B is also directly dependent on the implementation of a, then it may cause cyclic dependence. A common problem is that when compiling a module, you need to include the CPP file directly into the B module, while compiling B will also include the CPP file of a directly.
5. Interface separation principle (the Interface segregation Principle ISP)
The modules are separated by an abstract interface rather than strongly coupled by a specific class. Interface-Oriented Programming
6, "Dimitri" law
Also known as the least knowledge principle, that is, an object should have as little knowledge of other objects as possible
① in the division of classes, a class with weak coupling should be created;
② in the structure design of the class, each class should minimize the access rights of the members;
③ in the design of class, whenever possible, a class should be designed to be invariant class;
④ on references to other classes, an object's reference to other objects should be minimized;
⑤ try to reduce the access rights of the class;
⑥ use serialization function cautiously;
⑦ do not expose class members, but should provide the appropriate accessors (attributes).
7. Combination/Aggregation principleinheritance is a strongly coupled structure in which the parent class changes and the subclass must change. Synthesis/Aggregation Reuse principle: Use composition/aggregation as much as possible and do not use class inheritance as much as possible. The advantage of this is that the first use of the composition/aggregation of the object will help us keep each class encapsulated and focused on a single task. Such classes and class inheritance hierarchies remain small and are unlikely to grow into uncontrollable behemoths.
Also called the synthetic multiplexing principle. The principle is to use some existing objects in a new object through association relationships, including combinatorial relationships and aggregation relationships, to make them part of the new object, and the new object to reuse its existing functionality by delegating methods that call existing objects. That is, to try to use the class's composition reuse, try not to use inheritance.
is to use some existing objects inside a new object to make it part of the new object, and the new object is to reuse the existing functionality by delegating to those objects. This principle has a short description: Try to use composition, aggregation, and try not to use inheritance.
1) The only way to access an ingredient object from a new object is through the interface of the Component object
2) This reuse is a black-box reuse because the internal details of the constituent objects are invisible to the new object.
3) This multiplexing can be performed dynamically during runtime, and new objects can dynamically reference objects of the same type as the constituent object
4) Synthesis, aggregation can be applied to any environment, and inheritance can only be applied to a limited number of environments to
5) A common cause of incorrect use of composition, aggregation, and inheritance is the erroneous "has-a" relationship as a "is-a" relationship. If the two classes are "has-a" relationships then you should use compositing, aggregation, and, if it is a "is-a" relationship, use inheritance
In object-oriented design, there are two basic methods for reusing existing designs and implementations in different environments, that is, by combining/aggregating relationships or through inheritance.
1) Inheritance reuse: Easy to implement, easy to expand. Destroying the encapsulation of the system, the implementation inherited from the base class is static, impossible to change at run time, not flexible enough, and can only be used in a limited environment. ("White box" multiplexing)
2) Combination/aggregation multiplexing: a relatively low degree of coupling, optionally invoking the operation of a member object, and can be performed dynamically at run time. ("black box" multiplexing)
Combination/aggregation can make the system more flexible, the coupling between classes and classes is reduced, and the change of one class has less effect on other classes, so it is generally preferred to use combination/aggregation to achieve reuse;
The second is to consider inheritance, in the use of inheritance, the need to strictly follow the Richter substitution principle, the effective use of inheritance will help to understand the problem, reduce complexity, but abuse of inheritance will increase the difficulty of system construction and maintenance and the complexity of the system, it is necessary to carefully use inheritance reuse.
three or six great viewpoints
Multiplexing (reusibility)
Extension (Extensibility)
Separation (separability)
Changes (change)
Simplicity (Simplicity)
Consistent (coherance)
Three characteristics, seven principles and six viewpoints of object-oriented programming
