Object-oriented principles and features

一、五个 Design principles:

Single duty principle, open closure principle, dependency inversion principle, interface isolation principle and Liskov (Richter) substitution principle.

2. Single principle of responsibility

   For a single responsibility principle, the core idea is: A class, it is best to do only one thing, only a change that caused it. The principle of single responsibility can be regarded as the extension of low coupling, cohesion in object-oriented principle, defining responsibility as the cause of change, in order to improve cohesion to reduce the cause of change. The more responsibilities that may cause it to change, the more it will lead to a dependency on responsibility, which has an impact on each other, thus greatly damaging the cohesion and coupling degree. A single function in the general sense is that there is only one single feature, and do not implement too many functional points for the class to ensure that the entity has only one cause for it to change.

4. Open closure principle

       for the open closure principle, it is the core of all object-oriented principles, In the final analysis, the goal of software design is to package change and reduce coupling, and the open closure principle is the most direct embodiment of this goal. The core idea of the

       Open closure principle is that software entities should be extensible and non-modifiable. That is, open to the extension, to modify the closed.

       Therefore, the open closure principle is mainly embodied in two aspects: 1, open to expansion, meaning that there are new requirements or changes, the existing code can be extended to adapt to the new situation. 2, to modify the closure, means that once the design of the class, you can complete its work independently, and do not make any attempt to modify it.

       The core idea of implementing open and closed closures is to abstract programming, not specific programming, because abstractions are relatively stable. So that the class depends on the fixed abstraction, so the modification is closed, and through the object-oriented inheritance and polymorphism mechanism, it can realize the inheritance of the abstract class, by covering its methods to change the inherent behavior, to realize the new expansion method, so it is open.

       "Demand always changes" there is no immutable software, so we need to use closed open principle to close the change to meet the demand, but also to maintain the internal software packaging system stability, not affected by the change in demand.

6. dependency inversion principle

        for the dependency inversion principle, The core idea is that it relies on abstraction. In particular, high-level modules do not rely on the underlying modules, both of which are dependent on abstraction;

       We know that dependencies are bound to exist between classes and classes, modules, and modules. When there is a tight coupling between the two modules, the best way is to separate the interface and implementation: To define an abstract interface between dependencies so that the high-level module calls the interface, and the underlying module to implement the definition of the interface, so as to effectively control the coupling relationship, to rely on the abstract design goals.

       The stability of the abstraction determines the stability of the system, because the abstraction is immutable, and the reliance on abstraction is the essence of object-oriented design and the core of the dependency inversion principle.

       dependence on abstraction is a common principle, and sometimes it is unavoidable to rely on detail, and it is necessary to weigh the trade-offs between abstraction and specificity, not the same way. Depending on the abstraction, it is programming the interface, not programming the implementation.

8. interface Isolation principle

       for the interface isolation principle, The core idea is to use multiple small, dedicated interfaces instead of a large total interface.

       Specifically, the interface isolation principle is that the interface should be cohesive, and the "fat" interface should be avoided. The dependency of a class on another class should be based on the smallest interface, and do not force reliance on the unused method, which is an interface pollution.

       interfaces effectively isolate detail and abstraction, embodying all the benefits of abstract programming, and interface isolation emphasizes the uniqueness of interfaces. But the fat interface has the obvious disadvantage, causes the realization the type must completely implement the interface all methods, the property and so on, but some time, the implementation type does not need all the interface definition, in the design this is "The waste", and in the implementation this will have the latent problem, the modification of the Fat interface will cause a series of client program to modify , sometimes it's a disaster. In this case, the decomposition of the Fat interface into a number of characteristics of the customization method, so that the client only relies on their actual invocation of the method, thereby relieving the client does not rely on the methods they do not use.

       The main means of separation are the following two kinds: 1, the separation of delegates, by adding a new type to entrust the client's request, isolate the client and interface directly dependent, but increase the system overhead. 2, multiple inheritance separation, through the interface multiple inheritance to achieve customer demand, this way is better.

10. Liskov substitution principle

    The core idea of the Liskov substitution principle is that subclasses must be able to replace their base classes. This idea is embodied in the constraints of inheritance mechanism, only the subclass can replace the base class, it can ensure that the system in the runtime to identify the subclass, which is the basis of ensuring inheritance reuse. In the specific behavior of the parent class and subclass, you must strictly grasp the relationship and characteristics in the inheritance hierarchy, replace the base class with the subclass, and the behavior of the program will not change. At the same time, this constraint, in turn, is not true, and the subclass can replace the base class, but the base class does not necessarily replace the subclass.

    The Liskov substitution principle mainly focuses on the establishment of abstraction and polymorphism on the basis of inheritance, so only by following the principle of Liskov substitution can we ensure that inheritance reuse is reliable. The way to do this is to interface-oriented programming: to abstract the public part into a base class interface or abstract class, and to support the same responsibilities in a subclass by extract the method of the parent class through the abstraction class.

    The Liskov substitution principle is about the design principle of the inheritance mechanism, violating the principle of Liskov substitution inevitably leads to violating the principle of open closure.

    The Liskov substitution principle can ensure that the system has good extensibility and realizes the abstraction mechanism based on polymorphism, which can reduce the code redundancy and avoid the type discriminant of the running period.

Two or three basic features

The three basic characteristics of object-oriented are encapsulation, inheritance, polymorphism.

1. Encapsulation

The package is best understood. Encapsulation is one of the object-oriented features and is the main feature of object and class concepts.

Encapsulation, which is the encapsulation of objective things into abstract classes, and classes can put their own data and methods only trusted class or object operation , to the untrusted information hiding.

2. Inheritance

One of the main functions of object-oriented programming (OOP) language is "inheritance". Inheritance refers to the ability to use all the functionality of an existing class and to extend these capabilities without rewriting the original class .

New classes created through inheritance are called "subclasses" or "derived classes."

The inherited class is called the base class, the parent class, or the superclass.

The process of inheritance is from the general to the special process.

To implement inheritance, it can be implemented through inheritance (inheritance) and combination (composition).

In some OOP languages, a subclass can inherit multiple base classes. However, in general, a subclass can have only one base class, and to implement multiple inheritance, it can be implemented by multilevel inheritance.

Inheritance concepts are implemented in three categories: implementation inheritance, interface inheritance, and visual inheritance.

? implementation Inheritance refers to the ability to use the properties and methods of a base class without additional coding;

? interface Inheritance refers to the ability to use only the names of properties and methods, but subclasses must provide the implementation;

? Visual Inheritance is the ability of a subform (class) to use the appearance of a base form (class) and to implement code.

When considering using inheritance, it is important to note that the relationship between the two classes should be a "belongs" relationship. For example, the Employee is a person and the Manager is a person, so these two classes can inherit the People class. But the Leg class cannot inherit the person class, because the leg is not a human.

abstract classes only define generic properties and methods that will be created by subclasses, and when creating abstract classes, use the keyword Interface instead of class.

OO development paradigm is roughly: dividing objects → abstract classes → organizing classes into hierarchical structures (inheritance and compositing) → Designing and implementing several stages with classes and instances.

3. polymorphic

Polymorphism (POLYMORPHISN) is a technique that allows you to set a parent object to be equal to one or more of his child objects, after which the parent object can operate differently depending on the attributes of the child object currently assigned to it. To put it simply, it is a sentence: A pointer to the parent class type is allowed to be assigned a pointer to the child class type.

To achieve polymorphism, there are two ways, covering, overloading .

overwrite refers to the practice of redefining the virtual function of a parent class by a subclass .

overloading, which means that multiple functions with the same name are allowed, and the parameter tables of these functions are different (perhaps the number of parameters is different, perhaps the parameter types are different, perhaps the two are different).

In fact, the concept of overloading is not "object-oriented programming", the implementation of overloading is: The compiler according to the function of a different parameter table, the name of the same name is decorated, and then the same name function is a different function (at least for the compiler). For example, there are two functions of the same name: function func (p:integer): Integer, and function func (p:string): integer; Then the compiler has done a modified function name may be this: Int_func, Str_func. The invocation of these two functions has been determined between the compilers and is static (remember: static). That is , their addresses are bound (early bound) at compile time, so overloading and polymorphism are irrelevant ! The true and polymorphic correlation is "overlay". When a subclass has redefined the virtual function of the parent class, the parent pointer is dynamically based on the different child-class pointers assigned to it (remember: it's dynamic!). Call to the function of the subclass, such that the function call cannot be determined during compilation (the address of the virtual function of the calling subclass cannot be given). Therefore, such a function address is bound at run time (late bonding). The conclusion is that overloading is only a linguistic feature, independent of polymorphism, and irrelevant to object-oriented! Quote a WORD from Bruce Eckel: "Don't be foolish, if it's not late, it's not polymorphic." "

So what is the role of polymorphism?

We know that encapsulation can hide implementation details and make code modular ; inheritance can extend existing code modules (classes); they are all designed to-code reuse. And polymorphism is for another purpose--interface reuse! The role of polymorphism is to ensure that classes are called correctly when inheriting and deriving a property of an instance of any class in the family tree.

Other:

Generalization (generalization)

Chart 1 generalization

In, the hollow triangle represents an inheritance relationship (class inheritance), which is referred to as generalization (generalization) in UML terminology. Person is the base class, Teacher (Teacher), Student (student), Guest (guest) is a subclass.

If B is logically "one" of a and all functions and properties of a are meaningful to B, then B is allowed to inherit the functions and properties of a.

For example, a teacher is a person and Teacher is the "one" (a kind of) of persons. Then class teacher can derive (inherit) from the class person.

If a is a base class and B is a derived class of a, then B inherits the data and functions of a.

If Class A and Class B are irrelevant, it is not possible to have B inherit the functionality and properties of a in order to make B more functional.

If logically B is the "one" (a kind of) of a, then B is allowed to inherit the functions and properties of a.

Aggregation (combination)

Chart 2 combination

If logically A is a "part" of B, then B is not allowed to derive from a, but to combine B with a and other things.

For example, the eye, Nose (Nose), Mouth (Mouth), ear (EAR) is a part of the head (head), so the class head should be composed of a group of eyes, Nose, Mouth, and ears, not derived (inherited).

The types of aggregation are divided into none, shared (aggregated), composite (combined) three categories.

Aggregation (aggregation)

Chart 3 sharing

In the above illustration, there is a diamond (hollow) representation of aggregation (aggregation) (aggregation type is shared), and the meaning of aggregation represents a has-a relationship. Aggregation is a relatively loose relationship, and aggregation class B does not need to be responsible for the aggregated class A.

Combination (composition)

Figure 4 Composite

The only difference between this picture and the above is that the diamond is solid, which represents a more robust relationship-the combination (composition) (The aggregation type is composite). The combination representation of the relationship is also has-a, but here, the life of A is controlled by B. A will be created with the creation of B and perish with the demise of B.

Dependency (Dependency)

Chart 5 dependency

The relationship between B and a is only a dependency (Dependency) relationship, which indicates that class B is affected if Class A is modified.

Object-oriented principles and features