Why use object-oriented programming

why use object-oriented programming

because object-oriented programming is based on 7 principles, this allows programs written in object-oriented programming to be extensible, maintainable, and reusable, and more flexible.

7 Major principles:

(online reading, interpretation is their own understanding, not necessarily, the standard please on-line)

1. Single Duty principle SRP (Responsibility Principle)
A class is only responsible for its own functions, which can reduce the complexity of classes, each of which has its own purpose, and it is easier to read, modify, and Debug.

2. Open closure principle OCP (open-close Principle)
is to write the basic code when a basic architecture, and then you can add new classes when needed to complete new functions or requirements, but the original code is not used (and preferably not) line changes. Can only add, can not change. (written for future requirements)
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)

              (not understand, the effect seems to be to let the specific implementation of the function of the class dependent on the abstract class (parent class) or interface, interface and abstract class is the lower code, And the implementation of the function is the high-level Class)
              specific dependency on the abstraction, upper layer dependent. Suppose B is a lower module, but B needs to use the function of a,
             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 is to 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. The upper module is difficult to avoid relying on the lower module, if B is also directly dependent on the implementation of a, then you can                     can 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)

(Not too understanding)
The modules are separated by an abstract interface rather than strongly coupled by a specific class. Interface-Oriented Programming

6, "Dimitri" law

（。。。。。。。。 is the class supposed to be as independent as possible? It should be the top of the interface separation is similar, an isolation module, one to make the class as independent as possible, functional singleness? Single responsibility principle? ）

also known as the least knowledge principle, That is, an object should have as little knowledge of other objects as possible
① in the class division, should create a weakly coupled class;
② in the structure design of the class, each class should minimize the access rights of the members;
③ in class design, whenever possible, a class should be designed as invariant class;
④ on references to other classes, one object should have a minimal reference to other objects,
⑤ Minimize access to the class,
⑥ use serialization sparingly,
⑦ not expose class members, and should provide accessors (attributes).


also called the principle of synthetic reuse. 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.

summarize object-oriented programming : Object-oriented (like: boyfriend or girlfriend), his/her requirements are the direction of your programming, you have to face him or her, or is a requirement for programming, object is a real existence, you have to consider his various needs.

So why object-oriented programming? That is to think of some possible situations that will be easier to accomplish in the future, with a single, isolated, open-closed, and so on basis where reusability is stronger and simpler.

For the understanding of the 7 principles of object-oriented, I am still too far away, just know, not to mention object-oriented programming, in the book of the project is often confused, I write as if not object-oriented.

However, this article I will deepen with the understanding, a little bit of the 7 principles of their own views, may have to write all the time.

Why use object-oriented programming