Relationships and differences between inheritance, implementation, dependency, association, aggregation, and composition

Reprint: http://blog.csdn.net/kevin_darkelf/article/details/11371353

Relationships and differences between inheritance, implementation, dependency, association, aggregation, and composition

These relationships are described separately:

Inherited

Refers to the ability of a class (called a subclass, sub-interface) to inherit the functionality of another class (called the parent class, the parent interface) and to augment its own new functionality, which is the most common relationship between a class and a class or interface and interface, in Java where such relationships are explicitly identified by the keyword extends, In the design of the general is not controversial;

Realize

Refers to a class class implementation of the interface interface (can be multiple) function, the implementation is the most common relationship between the class and interface, in Java such relationships through the keyword implements clearly identified, at design time is generally not controversial;

Depend on

It can be simply understood that a class A uses another Class B, which is contingent, temporary, and very weak, but changes in class B affect A; For example, if someone wants to cross the river and borrow a boat, then the relationship between the man and the ship is dependent; At the code level, For Class B as a parameter is used by Class A in a methods method;

Association

He embodies a strong dependency between the two classes, or the semantic level of the class and interface, such as me and my friends; this relationship is more than relying on the contingency, the relationship is not temporary, generally long-term, and the relationship between the two sides is generally equal, the association can be one-way, two-way At the code level, the associated class B appears as a class attribute in the association Class A, or the association Class A refers to a global variable of the type being associated with Class B;

Polymerization

Aggregation is a special case of association relationship, he embodies the whole and part, the relationship of ownership, that is, the relationship between the whole and the part is has-a, they can have their own life cycle, some can belong to multiple whole objects, can also be shared for multiple whole objects, such as computer and CPU, The relationship between the company and its employees, and the expression at the code level, and the association is consistent, can only be differentiated from the semantic level;

Combination

The combination is also a special case of the relationship, he embodies a contains-a relationship, which is stronger than aggregation, also known as strong aggregation, he also embodies the relationship between the whole and part, but at this time the whole and part is not divided, the whole life cycle end also means that part of the life cycle end , such as you and your brain; At the level of the code, the relationship is consistent and can only be differentiated from the semantic level;

There is little doubt about the inheritance and realization of these two relationships, they embody a kind of class and class, or the vertical relationship between the class and the interface; the other four relationships embody the class and class, or the reference between the class and the interface, the transverse relation, is more difficult to distinguish between, there are many things between the relationship to prepare for positioning is very difficult, These kinds of relationships are semantic level, so from the code level does not completely distinguish between the various relationships;

However, in general, the following relationships show the degree of strength: combination > Aggregation > Association > dependency;

Aggregation and composition are all associations, but they are two special associations because this is the same root, so there will be similarities between them. Let's look at how they differ.

The concept of aggregation and composition I'm sure you don't need me to go into this. Here's a direct example.

Cheng Teacher's "big talk" in the case of the wild goose is very appropriate here I borrowed a wild goose like lively afraid of loneliness so they have been living in a social life so there are geese flock every geese have their own geese flock each geese have a lot of geese and geese flock this relationship can be called aggregation In addition, each goose has two wings. The relationship between the wild Goose and the Wild Goose Wings is called the combination has this visible aggregation relationship obviously no combination close the geese will not be able to survive because of their group of geese, and the wild Goose wings can not be separated from the wild Goose and live alone--the class of combinatorial relationships has the same life cycle

Aggregation diagram:

Composition diagram:

The difference between these two types of relationships from the code is:

Constructors are different

Flock of wild Goose class:

[CSharp] View plaincopy

1. Public class Goosegroup
2. {
3. Public Goose Goose;
6. Public Goosegroup (Goose Goose)
7. {
8. this. Goose = goose;
9. }
10. }

[CSharp] View plaincopy

1. public class Goosegroup
2. {
3. Public Goose Goose;
6. Public Goosegroup (Goose Goose)
7. {
8. This.goose = goose;
9. }
10. }

Wild Goose Category:

[CSharp] View plaincopy

1. Public class Goose
2. {
3. Public Wings Wings;
5. Public Goose ()
6. {
7. wings=new wings ();
8. }
9. }

[CSharp] View plaincopy

1. public class Goose
2. {
3. Public Wings Wings;
5. Public Goose ()
6. {
7. Wings=new wings ();
8. }
9. }

The class in the aggregation relationship contains another class as a parameter
Wild Geese (Goose) are used as parameters to pass the values in the Goosegroup (The Wild Goose Class) (Goose) can be separated from the wild Goose class and exist independently.
The class that combines the relationships contains the instantiation of another class
Wild Goose (Goose) before instantiating, be sure to instantiate the Wings Class (Wings) Two classes tightly coupled together they have the same life cycle Wing class (Wings) can not be separated from the Wild Goose Class (Goose) and independent existence
The encapsulation of information is different
In the aggregation relationship, the client can know both the wild Goose and the wild goose, because they are independent
But in the combinatorial relationship, the client only knows the Wild goose class, does not know the existence of the wing class, because the wing class is tightly encapsulated in the Wild Goose class.

-------------------------------------------------------------------------------------------------------

uml-Generalization, association, aggregation, composition, dependency

I. Generalization relationship (generalization)

1. Description

Represents an inheritance relationship between a class and a class, an inheritance relationship between an interface and an interface, or a class-to-interface implementation relationship. A generalized relationship is from a subclass to a parent class, as opposed to an inherited or implemented method.

2. Example diagram

3. Performance

Parent class Parent class instance =new subclass ();

4. For example

Class animal{};

Class Tigger:public animal{};

Class Dog:public animal{};

animal* panimal = new Dog;

II. Association Relationship (Association)

1. Description

For two relatively independent objects, when an instance of one object has a fixed correspondence with some specific instance of another object, the two objects are associated.

Represents a join between a class and a class, with two-way associations and one-way associations, two-way associations with two arrows or no arrows, and one-way associations with an arrow representing the direction of the association.

An association relationship exists as an instance variable, and at each associated endpoint there can also be a cardinality (multiplicity), indicating that the class of this end point can have several instances.

2. Example diagram

3. Performance

Two-Way association in the code of the performance of both sides have a pointer to each other, of course, can also be a reference or value.

Association relationships are implemented using instance variables.

4. For example

Eg.1

One-Way Association

Class person{};

Class Friend

{

person* Mpperson;

};

Eg.2

Bidirectional correlation

Class A;

Class B

{

A * PA;

};

Class A

{

b* PB;

};

Eg.3

Self-correlation

Class C

{

c* PC;

};

Iii. Aggregation Relationship (aggregation)

1. Description:

One kind of association relation, is strong association relation. Aggregation is the relationship between the whole and the individual. The aggregation relationship is also implemented through instance variables. For example, cars, engines, tires, a car object consists of an engine object, four tyre objects.

When there is a whole-part relationship between classes, we can use combinations or aggregations.

2. Example diagram

3. Performance

As with associative relationships, aggregation relationships are also implemented by instance variables. There is no way to differentiate the relationship and the aggregation relationship, and the difference between the two can be better differentiated by semantics.

4. For example

Class cpu{};

Class memory{};

Class computer

{

cpu* mpcpu;

memory* mpMemory;

};

Iv. Combinatorial relationships (synthetic relationships) (composition)

1. Description:

The synthetic relation is also a kind of correlation relation, which is stronger than the aggregation relationship. Synthetic relationships are not shared. For example people have limbs, first-class.

Represents the relationship between a whole and a part of a class, with a uniform lifetime for parts and the whole in a composite relationship. Once the whole object does not exist, some objects will not exist. There is a common life-death relationship between some objects and the whole object.

2. Example diagram

3. Performance

4. For example

Same as aggregation, but semantically different.

Class leg{};

Class arm{};

Class Person

{

Leg Mleg;

ARM MArm;

};

V. Dependency relationship (Dependency)

1. Description:

For two relatively independent objects, when one object is responsible for constructing an instance of another object, or a service that relies on another object, the two objects are primarily dependent.

Unlike association relationships, dependencies are passed in as parametric variables into a dependent class, and dependencies are unidirectional, to avoid two-way dependencies. In general, there should be no bidirectional dependencies.

Dependency is a weak association, as long as one class is used to another class, but the relationship to another class is not too obvious (it can be said that "uses" the Class), you can consider this relationship as a dependency.

2. Example diagram

3. Performance

Dependencies are represented in local variables, parameters of methods, and calls to static methods

4. For example

Class car{};

Class house{};

Class Person

{

void Buy (car& Car) {}

void Buy (house* phouse) {}

};

Vi. the difference between relationships

1. Aggregation and Combination

(1) Aggregation and combination are a kind of binding relationship, but the extra has a whole-part meaning.

(2) different life cycle of parts

In an aggregation relationship, the entire piece does not have a life cycle of the part, so the part is not deleted when the whole piece is deleted. Furthermore, multiple pieces can share the same part.
In a composite relationship, the entire piece has a life cycle of the part, so the part must be deleted when the whole piece is deleted. Also, multiple pieces cannot share the same part at the same time.

(3) The aggregation relationship is a "has-a" relationship, and the combined relationship is a "contains-a" relationship.

2. Associations and Aggregations

(1) Performance at the code level, and the association is consistent, can only be differentiated from the semantic level.

(2) The difference between association and aggregation is mainly semantically, and the associated two objects are generally equal, for example, if you are my friend, aggregation is generally not equal.

(3) Association is a structured relationship in which an object is associated with another object.

(4) Association and aggregation are depending on the problem domain, for example, in the field of concern about the car, the tyre must be combined in the car class, because it has no meaning to leave the car. But in the business of selling tires, even if the tires leave the car, it makes sense, and it can be aggregated.

3. Associations and Dependencies

(1) in association, it is a kind of strong dependency between the two classes, or the semantic level between the class and the interface, such as me and my friends; this relationship is more than relying on the contingency, the relationship is not temporary, generally long-term, and the relationship between the two is generally equal.

(2) In the dependency relationship, it is simple to understand that a class A uses another Class B, which is contingent, temporary, and very weak, but changes in class B affect a.

4. Comprehensive comparison

These relationships are semantically level, so it is not possible to completely differentiate the relationships from the code level, but in general, the latter relationships are shown in the following ways:

Combination > Aggregation > Correlation > dependencies;

--------------------------------------------------------------------------------------------------------------- --------------------------------

UML line Arrows

Relationship

The following example will show the relationships independently for a specific purpose. Although grammatically correct, these examples can be further refined to include more semantics within their valid range.

Dependency (Dependency)

A "use" relationship between entities implies that the specification of an entity changes and may affect other instances that depend on it ( figure D). More specifically, it can be converted to any type of reference to a class or object that is not within the scope of the instance. This includes a local variable, a reference to an object obtained through a method invocation (as shown in the following example), or a reference to a static method of a class (without an instance of that class). You can also use dependencies to represent the relationship between packages and packages. Because the package contains classes, you can represent the relationship between packages and packages based on the relationships between the classes in those packages.

Figure D

Association (Association)

A structured relationship between entities indicates that objects are interconnected. The arrows are optional and are used to specify navigation capabilities. If there are no arrows, hinting is a two-way navigation capability. In Java, the Association ( Figure E) is converted into a variable of an instance scope, just as the code shown in the Java area of Figure E. Additional modifiers can be attached to an association. The multiplicity (multiplicity) modifier implies a relationship between instances. In the model code, an employee can have 0 or more timecard objects. However, each timecard only belongs to a single Employee.

Figure E

Aggregation (Aggregation)

Aggregation ( figure F) is a form of association that represents a global/local relationship between two classes. Aggregation implies that the whole is conceptually at a higher level than the local, and the association implies that two classes are conceptually at the same level. Aggregations are also converted to an instance-scoped variable in java.

The difference between association and aggregation is purely conceptual, and is strictly reflected in semantics. Aggregation also implies that there are no loops in the instance diagram. In other words, it can only be a one-way relationship.

Figure F

Synthesis (composition)

Synthesis ( Figure G) is a special form of aggregation that implies a "partial" lifetime responsibility within the "whole". The composition is also unshared. Therefore, although the local does not have to be destroyed with the overall destruction, but the overall responsibility to maintain a local survival, or be responsible for destroying it. Local cannot be shared with other whole. However, the whole can transfer ownership to another object, which will then assume the lifetime responsibility.

The relationship between employee and timecard may be better represented as "compositing" rather than "associative".

Figure G

Generalization (generalization)

Generalization ( figure H) represents the relationship between a more generalized element and a more specific element. Generalization is a UML element that is used to model inheritance. In Java, this relationship is represented directly by the extends keyword.

Figure h

Implementation (Realization)

The example ( figure I) relationship specifies a contract between two entities. In other words, one entity defines one contract and the other guarantees the performance of the contract. When modeling a Java application, the implementation relationship can be expressed directly with the implements keyword.

Figure I

--------------------------------------------------------------------------------------------------------------- --------------------------------

UML Class diagram relationship is mainly related, dependent, generalization, implementation, and so on, then their representations are familiar to you, this article is like you introduce the UML class diagram relationship representation method.

AD:

This section and everyone to learn about the UML class diagram relationship representation, mainly including association, aggregation, generalization, implementation, dependency and other content, hope that through this section of the study of UML class diagram relationship representation method has a certain grasp. Here is a detailed description.

UML Basics

Types of relationships between 1:UML classes

2: Association

The Association in a UML class diagram relationship describes a discrete connection between an object or an instance in a system, associating information with relationships between objects in the system.

2.1 Association notation

2.2 Aggregation and combination

3: Generalization, inheriting "generalization"

The generalization relation in UML class diagram relationship is the relation between the general description of the class element and the concrete description, and the concrete description is based on the general description, and it is extended.

4: Implement "realization"

The implementation relationship in a UML class diagram relationship connects a model element, such as a class, to another model element, such as an interface, where the interface is simply a description of the behavior rather than a struct or implementation.

5: Dependent on "dependence"

A dependency in a UML class diagram relationship represents a semantic relationship between two or more model elements. It only connects the model elements themselves and does not require a set of instances to express its meaning. It represents a situation in which certain changes in the provider require or indicate changes in the customer in the dependency relationship.

5.1 Types of dependence

Access: Allow one package to access another package "access"

Binding: Assigning a value to a template parameter to generate a new model element "bind"

Invocation: Declaring a class calling method "call" of another class

Export: Declares an instance that can "derive" from another instance

Friend: Allows an element to access another element regardless of the visibility of the element being accessed "friend"

Introduced: allowing one package to access the contents of another package is not added as part of the access package alias "Import"

Instantiation: A method of one class generates the life "instantate" of an instance of another class

Parameters: The relationship between an operation and his parameters "parameter"

Implementation: The mapping relationship between the description and the fact "realize"

Refinement: Declares a mapping relationship with two different levels of elements "refine"

Send: The relationship between the sender of the signal and the recipient of the signal "send"

Trace: Declares a connection between elements in different models, without mapping the exact "trace"

Use: Declares the use of a model element requires another model element that already exists in order to correctly implement the function of the consumer (invocation, instantiation, parameters, send) "use"

6: Constraints

Constraints in UML class diagram relationships can be used to represent a variety of non-local relationships, such as constraints on an association path. Constraints can be used in particular to describe the existence of an attribute (where x is the C condition) and the general nature (for all y in Y, condition D must be established).

7: Example

An instance is a running entity that has an identity, that is, it can be distinguished from other running entities. It has a value at any moment, and the operation value of the instance is changed as well.

--------------------------------------------------------------------------------------------------------------- --------------------------------

The following relationship exists between classes and classes:
(1) Generalization (generalization)
(2) Association (Association)
(3) Dependence (Dependency)
(4) polymerization (Aggregation)
Examples of UML diagrams and application code:
1. Generalization (generalization)
Generalization
Represents an inheritance relationship between a class and a class, an inheritance relationship between an interface and an interface, or a class-to-interface implementation relationship. A generalized relationship is from a subclass to a parent class, as opposed to an inherited or implemented method.
[Specific performance]
Parent class Parent class instance =new subclass ()
[UML Diagram] (Fig. 1.1)
Figure 1.1 Generalization relationship between animal class and Tiger class and dog class
[Code Performance]
Class animal{}
Class Tiger extends animal{}
public class Test
{
public void Test ()
{
Animal a=new Tiger ();
}
}
2. Dependency (Dependency)
Dependency
For two relatively independent objects, when one object is responsible for constructing an instance of another object, or a service that relies on another object, the two objects are primarily dependent.
[Specific performance]
Dependencies are represented in local variables, parameters of methods, and calls to static methods
[Example of Reality]
For example, if you are going to screw the screws, do you want to use (i.e. rely on) a screwdriver (screwdriver) to help you complete the screw (screw) work
[UML Performance] (Fig. 1.2)
Figure 1.2 Dependency between the person class and the screwdriver class
[Code Performance]
public class person{
/** Screws */
public void screw (screwdriver screwdriver) {
Screwdriver.screw ();
}
}
3. Association (Association)
Associated
For two relatively independent objects, when an instance of one object has a fixed correspondence with some specific instance of another object, the two objects are associated.
[Specific performance]
Association relationships are implemented using instance variables.
[Example of Reality]
For example, the customer and the order, each order corresponds to a specific customer, each customer corresponds to some specific orders, such as companies and employees, each company corresponds to some specific employees, each employee corresponds to a specific company
[UML Diagram] (Fig. 1.3)
Figure 1.3 Relationship between company and employee
[Code Performance]
public class company{
Private employee employee;
Public Employee GetEmployee () {
return employee;
}
public void Setemployee (employee employee) {
This.employee=employee;
}
Company operations
public void Run () {
Employee.startworking ();
}
}
(4) polymerization (Aggregation)
Aggregate
When object A is added to object B and becomes part of Object B, the aggregation relationship is between object B and object A. Aggregation is one kind of correlation relation, it is strong association relation, emphasizing the relation between whole and part.
[Specific performance]
As with associative relationships, aggregation relationships are also implemented by instance variables. There is no way to differentiate the relationship and the aggregation relationship, and the difference between the two can be better differentiated by semantics.
[Differences between associations and aggregations]
(1) The two objects involved in the association relationship are at the same level. For example, people and bicycles are an association, not an aggregation, because people are not made up of bicycles.
The two objects involved in the aggregation relationship are at an unequal level, one representing the whole, and the other representing the part. For example, the computer and its monitor, keyboard, motherboard and memory are aggregation relationships, because the motherboard is a part of the computer.
(2) for two objects with aggregation relationships, especially strong aggregation relationships, the overall object restricts the life cycle of its constituent objects. The object of a partial class cannot exist alone, its life cycle depends on the life cycle of the object of the whole class, and when the whole disappears, the part disappears. For example, Zhang San's computer is stolen, then all the components of the computer are not there, unless Zhang San in advance to remove some of the computer components (such as hard disk and memory).
[UML Diagram] (Fig. 1.4)
Figure 1.3 Aggregation relationship of computers and components
[Code Performance]
public class computer{
Private CPU CPU;
Public CPU getcpu () {
return CPU;
}
public void SetCPU (CPU CPU) {
THIS.CPU=CPU;
}
Turn on your computer
public void Start () {
CPU operation
Cpu.run ();
}
}

--------------------------------------------------------------------------------------------------------------- --------------------------------

Relationships in class diagrams and class diagrams

1. Class diagram and object graph

Class Diagram are graphs that show classes, interfaces, and the static structure and relationships between them. The most basic unit is the class or interface.

A class diagram can represent a relationship between a class (or an interface), or a relationship between objects. The following is a typical class diagram:

Class diagrams are generally divided into several parts: class names, properties, methods. The following are explained separately.

(1) Class name

The car above is the class name, if the class name is a traditional word, then the class is a concrete class, if the class name is italicized, then the class is an abstract class.

(2) List of attributes

Properties can be public, protected, private. Public front of the icon is a diamond, protected corresponding to the Diamond plus key, private corresponding to the diamond lock. Of course, this is just a way of showing. I use rational Rose, and if you use other software, you may also use the + 、-、 #表示: + for Public,-for private, #代表protected.

(3) method list

The method can be public, protected, private. Public front of the icon is a diamond, protected corresponding to the Diamond plus key, private corresponding to the diamond lock. Of course, this is just a way of showing. I use rational Rose, and if you use other software, you may also use the + 、-、 #表示: + for Public,-for private, #代表protected.

For a static property, the property name is underlined. As shown in.

In addition, class diagrams can represent relationships between classes as well as relationships between objects. The difference between the two is that an underscore is added to the object name in the object graph.

2. Relationships in class diagrams

(1) Generalization: Generalized, generalized

Generalization represents the inheritance relationship between classes and classes, the inheritance relationship between interfaces and interfaces, and the implementation relationship between classes and interfaces. If embodied in the Java language, that is the reaction extends and implements keywords. The typical class diagram is as follows:

(2) Association: Association Relationship

An association describes a connection between a class and a class, which indicates that a class knows the properties and methods of another class. Association relationships can be one-way or two-way. In the Java language, a one-way association is implemented by holding a reference to the associated object in the same way as an instance variable. In general, it is not recommended to use a bidirectional association relationship. The following example describes a one-way association.

The above class diagram shows the relationship between the rider and the horse. One of the instance variable types in rider is horse.

Each connection has two endpoints, rider and horse are endpoints, and each endpoint can have (optional) a cardinality (multiplicity), indicating that the class can have several instances. This is similar to the 1:n in the database, m:n these relationships. We can add cardinality to the above example:

The above represents a 1-to-n relationship between the rider and the horse.

(3) Aggregation: Aggregation Relationship

The aggregation relationship is part of the association relationship and is a very strong association relationship. The aggregation relationship is more about the relationship between the whole and the part. For example, the relationship between the car and the door and the engine. ：

As with associative relationships, aggregation relationships are also implemented through instance variables. Simply from the grammatical point of view, it is impossible to judge the relationship and the aggregation relation.

(4) Composition: Combinatorial relationships

The combination relationship is also one of the related relationships, which is a stronger relationship than the aggregation relationship. As we mentioned earlier, the aggregation relationship represents the relationship between the whole and the part, and the combinatorial relationship is based on the aggregation relationship, which indicates the relationship between the integral and the part. That is, the object representing the whole needs to be responsible for the life cycle of the object representing the part.

"The object representing the whole is responsible for maintaining the survival of the object representing the part, and in some cases is responsible for the annihilation of the object representing the part." An object representing a whole can sometimes pass an object representing a part to another object, and it is responsible for the life cycle of the object that represents the part. In other words, objects that represent parts can only be combined with one object at a time. and is exclusively responsible for its life cycle by the latter. "-Java and Patterns"

We take an example of the relationship between man and arm, and the class diagram of the combinatorial relationship is as follows:

(5) Dependency: Dependencies

A dependency represents a class that relies on the definition of another class. Dependencies are single-directional. People eat apples, so people depend on apples. The class diagram is as follows:

In general, objects that are dependent are often in the form of local variables, method parameters, and, unlike association relationships, they do not exist in the form of member variables since they are in the object. This is worth noting. In addition, each dependency has a name. The name of the dependency above is eats.

These are the relationships between class diagrams and common class diagrams.

Relationships and differences between inheritance, implementation, dependency, association, aggregation, and composition