First, the relationships between classes can be divided into association, dependency, and inheritance from a macro perspective. Association has two special cases: Aggregation and combination, however, in UML2.X, a relationship is merged and combined.
From the usage frequency, the Association (including aggregation and combination) relationship is the most widely used, followed by dependency and inheritance.
Differences between Association and dependency:
The relationship between classes indicates the strong relationship between classes, and dependency indicates the weak relationship between classes;
From the point of view of the time between classes, Association indicates the "persistent" Relationship between classes. This relationship generally indicates an important relationship between businesses and needs to be saved, or "persistence" is required, or it needs to be stored in the database. For example, Student and Class in the Student management system, which Class A Student object belongs to is an important business relationship. If this relationship is not saved, the system cannot manage it. In addition, dependency indicates a "temporary and temporary" Relationship between classes, which does not need to be saved, such as Student class and StuEditScreen (Student logon interface) A dependency between classes. The StuEditScreen class depends on the Student class and displays and edits Student information based on the Student object information.
The relationship between the design classes follows the principle: first, judge whether there is a "Link" between the classes. If it is not a "dependency", if it is not an association, is dependency
Dependency is generally one of the following situations: a. ClassA has a ClassB parameter type, which becomes coupling; b. The parameter type of a method in ClassA is a property of ClassB. This situation becomes tightly coupled. The implementation of a method in c and ClassA instantiates ClassB; d. the type of the return value of a method in ClassA is ClassB. If one of the above four situations occurs, the two classes may be dependent.
Dependency: it is the connection between classes, and Dependency is always one-way. Dependency indicates that one class depends on the definition of another class. In the following example, class A depends on class B, C, and D.
View plaincopy to clipboardprint?
Public class {
Public B getB (C c, D d ){
E e = new E ();
B B = new B (c, d, e );
}
}
Public class {
Public B getB (C c, D d ){
E e = new E ();
B B = new B (c, d, e );
}
}
Association is a structural relationship, indicating that the object of one thing is associated with the object of another thing. Given a connection to two types of associations, you can navigate from one class object to another class object.
The association can have a direction, that is, navigation. Generally, the navigation is bidirectional and no arrows need to be marked online. In most cases, navigation is unidirectional and can be indicated by an arrow. Association is generally represented as an attribute (member variable) in the Code. For example, in the following example, class A is associated with class B.
View plaincopy to clipboardprint?
Public class {
Private B;
}
Public class {
Private B;
}
If B is also associated with A, they are two-way associations.
View plaincopy to clipboardprint?
Public class B {
Private A;
}
Public class B {
Private A;
}
7. Aggregation: a type of strong association. Aggregation is the relationship between the whole and the individual. For example, the relationship between the automobile and the engine type is the relationship between the whole and the individual.
Like the association relationship, the aggregation relationship is also implemented through instance variables.
* ** An association involves two classes at the same level. In an aggregation relationship, two classes are at an unequal level, one representing the whole and the other representing the part. (Association and aggregation are only syntactically inseparable. You need to check the logical relationship between involved classes .)
8. Composition: a type of association, which is stronger than an aggregation relationship. It requires that the objects represented in common aggregation relationships are responsible for representing the lifecycle of some objects, and the compositing relationships cannot be shared.
The whole object is responsible for keeping the object alive. In some cases, it is responsible for destroying some objects. An object that represents the whole can pass objects that represent some parts to another object, and the latter is responsible for the lifecycle of this object. In other words,
* ****** Indicates that some objects can only be combined with one object at each time point, and the latter is responsible for its lifecycle.
LeeLin: