Three basic characteristics of object-oriented transfer

The three basic characteristics of object-oriented are encapsulation, inheritance, polymorphism. PackageThe 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. InheritanceOne 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. Implementing inheritance is the ability to use the properties and methods of a base class without additional coding; O interface inheritance is the ability to use only the names of properties and methods, but the 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. polymorphicPolymorphism (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. Concept explanationGeneralization (generalization) Diagram 1 generalization in, the hollow triangle represents the inheritance relationship (class inheritance), in the UML terminology, this relationship is called generalization (generalization). 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) Diagram 3 shares the above illustration, there is a diamond (hollow) representation of aggregation (aggregation) (aggregation type is shared), and the meaning of the 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) Chart 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) Diagram 5 depends on the relationship between B and A is just a dependency (Dependency) relationship, which shows that if Class A is modified, Class B is affected.

uml for many people should not be a strange concept, the past two years, the UML has been more and more discussion. Originally the UML and my topic does not seem to have much to do with the relationship (it is language-independent, it can even be said that it is a language-for communication). I'm talking about it for two purposes:
1. UML is for object-oriented software development, and C + + is such a language
2. UML is more and more used in the design, and the next one is ready to discuss the design pattern, if you do not understand UML, then can not go on

UML, full name: Unified Modeling Language, which is designed to visualize, detail, construct, and document the graphics language for software-intensive products. UML is based on a number of previous ideas summed up the results, 1997 by the OMG adopted and become the standard (so in the "design mode" book if you see the standard is not the same place, do not wonder, the book is 95). For a historical and more detailed description of UML, refer to the UML reference manual. UML is composed primarily of a series of views, including static view, use Case view (Activity view), and so on, the different diagrams are not the same, but for the developer (or for my next article), More importantly, the sequence diagram (Sequence diagram) in the class diagram (diagram) and interactive view (Interaction view) in the static view, notice the difference between the view and the diagram.

Class diagram
Static view describes the structure of the object, the most common is the class diagram, the class diagram can help us more intuitive understanding of a system architecture, sometimes, describing the system snapshot of the object graph (diagram) is also very useful. Here, we mainly introduce the class diagram, the following diagram is a simple class diagram:

In a class diagram, a class is represented by a rectangle, such as, in which 4 classes are defined, base, A, B, and C, and the relationships between classes are represented by various lines and other symbols, in which the hollow triangle represents the inheritance relationship, which in the term of UML is called generalization (generalization), So the above class is represented by an equivalent code:
Class base{...};
Class A:public base{...};
Class B:public base{...};
Class C:public base{...};

Let's look at the next picture:

The only difference between this picture and the top is the addition of a member in the base class, a private integer _x (UML term property) and a public fun () function (method), whether the internal details of these classes are required, and there is no limitation in the UML itself. It all depends on how you use it, and the usefulness of UML is to help you understand the system, so as long as you think it's clear enough, that's enough, no more complications.
Then look at the third picture:

The arrows in the diagram above represent a relationship, the other side of the Arrow has a diamond (hollow) representation of the aggregation (aggregation), the meaning of the aggregation represents the has-a relationship, and its equivalent code is as follows:
Class a{...};
Class b{* TheA, ...};
Aggregation is a relatively loose relationship, and aggregation class B does not need to be responsible for the aggregated class A.
The following figure:

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 combination representation of the relationship is also has-a, but here, the life of A is controlled by B, usually, the equivalent code is as follows:
Class a{...};
Class B{a TheA;..};
A will be created with the creation of B and perish with the demise of B.

：

The relationship between B and a is only a dependency, which shows that if Class A is modified, then Class B is affected, and a simple example is:
Class a{...};
Class B{fun (A params);..};

The common relationship is that we use these, through these relationships and class diagrams of classes, we can graphically describe a system design part, when you are accustomed to using UML, you will find that this is often more than you tell the companion class, such as the derivation of class, derived classes and so on what kind of relationship is much easier.

Sequence diagram:
Another common graph in UML is the sequence diagram in the interactive view, in the previous process language, we often use flowcharts to describe how a function (System) works, and in object-oriented systems, this is obviously not feasible, and sequence diagram is to solve the problem.
Assume the following pseudo-code:

Class circle{
Public
void FillColor ()
{
            //...
        }
void Draw ()
{
FillColor ();
}
};
Class window{
Public
void Drawcircle ()
{
     _circle.draw ();
}
Private
Circle _circle;
};

For the following call:
Window wnd;
Wnd.drawcircle ();
The corresponding sequence diagram is as follows:

The block above represents the participating object, the vertical dashed line represents the object's lifeline, and the box indicates activation, where the arrow indicates a call message (and can have a loopback return), or, if it is an asynchronous message, a half-arrow indicating that draw represents a self-invocation

At this point, the most commonly used in UML (from the developer's perspective), of course, the content of UML is far more than these, the introduction of this is just a few simple generalizations, and the UML itself is constantly developing, no matter how, I think the UML will be more and more in our development process, In particular, for the next design pattern we are going to introduce, the class diagram is the main description tool (at that time you will experience the superiority of the UML description).
If you have seen the book "Design Mode", you will find that there are some subtle differences with what I described above, don't be nervous, "design mode" is the work of GOF95 years, when the UML has not yet formed, and, among other things, it is the OMT method (Jim Rumbaugh, the modeling technology published by GE- -object Modeling Technique) and Booch method. If you feel that UML is a bit confusing, do not have to be nervous, UML itself is just an auxiliary tool, its purpose is to help you describe the system, not complicated your work, if your system is very simple, a word can be said very clearly, then do not use UML, if you just want to explain the relationship between classes, Rather than the interface description of the class, then the simple description like the first picture is good, so don't go after the details, as long as you can explain the problem, then your goal is reached (even if you don't have to obey the rules completely).

Bibliography :
Design patterns-the basis of reusable object-oriented software
Author: Erich Gamma Translator: Li Yingjun Ma Xiaoxing Cai Min Liu Jianzhong Machinery Industry Press 2000

UML Reference Manual Author: James rumbaugh Ivar Jacobson Grady Booch
Translator: Yiu Shuzhen Tang Fagen Machinery Industry Press 2001

UML Essentials-A concise guide to the Standard Object Modeling Language (2nd edition)
Author: Martin Fowler&kendall Scott Translator: Xu Jiafu Tsinghua University Press 2002

"Design Patterns Explained" Alan Shalloway, James R. Trott
Addison-wesley Pub 2001

Three basic characteristics of object-oriented transfer