Reprinted from: http://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html
I will not mention all the various elements of UML here, I just want to talk about the relationship between the various classes in the class diagram; it is enough to understand what the lines and arrows between the various classes in the class diagram mean. Cope with daily work and communication; at the same time, we should be able to match the meaning expressed by the class diagram with the final code; with this knowledge, there is no problem in looking at the design pattern structure diagram in the following chapters;
All graphics in this chapter are drawn using Enterprise Architect 9.2. For all examples, see design_patterns.EAP in the root directory.
start with an example
Please see the following class diagram, the relationship between classes is what we need to pay attention to:
- The class diagram structure of the car is <<abstract>>, indicating that the car is an abstract class;
- It has two inherited classes: car and bicycle; the relationship between them is the realization relationship, which is represented by a dashed line with a hollow arrow;
- The relationship between the car and the SUV is also an inheritance relationship, and the relationship between them is a generalization relationship, which is represented by a solid line with a hollow arrow;
- The relationship between the car and the engine is a combination, represented by a solid line with a solid arrow;
- There is an aggregate relationship between students and classes, represented by solid lines with hollow arrows;
- The relationship between the student and the ID card is represented by a solid line;
- Students need to use bicycles to go to school, and there is a dependency relationship with bicycles, which is indicated by a dotted line with an arrow;
Below we describe these six relationships;
relationship between classes
generalization
The inheritance structure of a class is expressed in UML as: generalization and realization:
The inheritance relationship is an is-a relationship; if two objects can be represented by is-a, it is an inheritance relationship: (.. is..)
eg: a bicycle is a car, a cat is an animal
The generalization relationship is directly represented by a hollow arrow; as shown in the following figure (A inherits from B);
eg: Cars are realized in reality, and specific objects can be defined by cars; there is a generalized relationship between cars and SUVs;
Note: In the final code, the generalization relationship is expressed as inheriting non-abstract classes;
Realize the relationship (realize)
The realization relationship is represented by a dashed line with a hollow arrow;
eg: "Car" is an abstract concept, which cannot be directly used to define objects in reality; only by specifying a specific subclass (car or bicycle) can it be used to define an object (the "car" class is abstracted in C++ Class representation, there is the concept of interface in JAVA, which is easier to understand)
Note: In the final code, the implementation relationship is expressed as inheriting the abstract class;
Aggregation
The aggregation relationship is represented by a straight line with a hollow diamond arrow, as shown in the following figure, indicating that A is aggregated to B, or that B is composed of A;
The aggregation relationship is used to represent the relationship between entity objects, and it represents the semantics that the whole consists of parts; for example, a department consists of multiple employees;
Different from the combination relationship, the whole and the part are not strongly dependent, even if the whole does not exist, the part still exists; for example, if the department is revoked, the personnel will not disappear, they still exist;
composition
The combination relationship is represented by a straight line with a solid diamond arrow, as shown in the following figure, indicating that A consists of B, or B consists of A;
Like the aggregation relationship, the composition relationship also expresses the semantics that the whole is composed of parts; for example, a company is composed of multiple departments;
However, the combination relationship is a special aggregation relationship with strong dependence. If the whole does not exist, the part does not exist either; for example, if the company does not exist, the department will also not exist;
association
The association relationship is represented by a straight line; it describes the structural relationship between objects of different types; it is a static relationship, usually independent of the operating state, and is generally determined by factors such as common sense; it is generally used to define the relationship between objects Static and natural structure; therefore, the relationship is a "strong relationship" relationship;
For example, there is an association between passengers and tickets; students and schools are an association;
The association relationship does not emphasize the direction by default, which means that the objects know each other; if the direction is particularly emphasized, as shown in the figure below, it means that A knows B, but B does not know A;
Note: In the final code, associated objects are usually implemented in the form of member variables;
Dependency
Dependencies are represented by a set of dashed lines with arrows; the following figure shows that A depends on B; it describes the relationship that an object will use another object during runtime;
Unlike an association relationship, it is a temporary relationship, usually generated during runtime, and changes with runtime; dependencies may also change;
Obviously, dependencies also have directions. Two-way dependencies are a very bad structure. We should always maintain one-way dependencies and prevent the occurrence of two-way dependencies;
Note: In the final code, the dependency relationship is reflected in the class constructor and the incoming parameters of the class method, and the arrow points to the calling relationship; the dependency relationship, in addition to temporarily knowing the other party, also "uses" the other party's methods and properties;