Three basic features of object-oriented and five design principles

一、三个 Basic Features

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

Package

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. 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 of inheritance refers to the ability to use the properties and methods of the 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 refers to the ability of a subform (class) to look and implement code using the base form (class).

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.

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 dynamic (remember: dynamic) According to the different child-class pointers assigned to it. 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. 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.

Concept explanation

Generalization (generalization)

Chart 1 generalization

In the above illustration, the hollow triangle represents an inheritance relationship (class inheritance), which is referred to as generalization (generalization) in the terminology of UML. 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 classes.

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. Two or five principles of design

"The Five Principles of object-oriented design" and the role of the principle of benign dependence in coping with change.

Single Responsibility principle (Single-resposibility Principle). "There should be only one reason for a class to cause it to change. "This principle is very familiar with the" high cohesion principle "extension, but by the" responsibility "is highly creative definition as" the cause of change ", making this principle is very operational, the master style. At the same time, this principle also reveals the cohesion and coupling, the basic way is to improve cohesion; If a class takes on too much responsibility, then these responsibilities will depend on each other, and a change in one's responsibilities may affect the fulfillment of another. In fact, the essence of ood is to reasonably carry out the assignment of duties of class.

Open closure principle (open-closed principle). "The software entity should be extensible, but not modifiable." "This principle closely revolves around the change, the change comes temporarily, if does not need to change the software actual genre source code, can expand its behavior, then this software entity design is satisfies the open closed principle." If we predict a change, or if a change has occurred, we should create an abstract class to isolate the similar changes that occur later. In Java, this abstraction refers to an abstract base class or interface; in C + +, this abstraction refers to an abstract base class or a purely abstract base class. Of course, there are no models that are appropriate for all situations, and we have to make choices about the changes that software entities should face.

Liskov substitution principle (liskov-substituion Principle). "Subtypes must be able to replace their base types. "This principle is closely related to the open closure principle, which is the substitution of sub-types, so that the use of the base type module can be expanded without modification." The Liskov substitution principle evolves from a contract-based design by declaring a "priori condition" and a "posteriori condition" for each method, and when defining a subclass, these "prior conditions" and "posterior conditions" must be observed. The current design based on the development of the momentum, the realization of the "Software Factory" "Assembly Production" dream is a strong support.

Dependency inversion principle (dependecy-inversion Principle). "Abstractions should not be dependent on detail, and detail should be dependent on abstraction." "This principle is almost the radical reform way of software design." Because the person solves the problem the thought process is the abstract after the concrete, from the general to the detail, therefore our gentleman output certainly is the abstract degree higher entity, then is the more detailed entity. Thus, "detail depends on abstraction" means that later reliance on the previous, which is the natural way to reuse. Moreover, abstract entities represent subsumed's understanding that people are always more likely to know them correctly, and are inherently immutable, and depend on them to be safe. The dependency inversion principle adapts to the law of human cognition process and is the symbol of object-oriented design.

Interface Isolation principle (Interface-segregation Principle). "Multiple dedicated interfaces are better than a single common interface. "This principle is the natural result of a single duty principle for interface design. An interface should ensure that instance objects that implement the interface can only be rendered as a single role, so that when the requirements of one client program change and the interface is forced to change, the likelihood of affecting other client programs is small.

The principle of benign dependence. "The dependencies that do not cause harm in practice are benign dependencies." Through analysis, it is not difficult to find that the core idea of this principle is "pragmatic", and it is very good to reveal the theoretical basis of "simple design" of "Extreme programming" in extreme programming. This principle can help us to resist the "Five principles of object-oriented design" and the temptation of design patterns, so as not to fall into the awkward situation of over-design (over-engineering), which brings unnecessary complexity.