Let's talk about our own understanding of the differences between dependency, association, aggregation, and combination.

When learning object-oriented design object relationships, the differences between dependency, association, aggregation, and combination are confusing. In particular, the last three types only have differences in semantics. Semantics refers to context and specific scenarios. Their Expressions in programming languages are basically the same, but they are basically the same and not the same. This is in my previous blogRelationship between classes in Design PatternsAs mentioned in, the following describes in detail how to accurately reflect dependency, association, aggregation, and combination in Java.

First, let's take a look at the definition of these four relationships in the book:

• Dependency relationships are links between classes. Dependency indicates that one class depends on the definition of another class. For example, a person can buy a car or a house. The person class depends on the definition of the car and house classes, because the person class references car and house. Different from associations, the person class does not have the attributes of the car and house types. The car and house instances are transmitted to the buy () method as parameters.In general, dependency is embodied in the local variables, method parameters, or static method calls in Java.
• Association is a join between a class and a class. It allows a class to know the attributes and methods of another class.The association can be bidirectional or unidirectional.In Java, associations are generally implemented using member variables.
• Aggregation is a type of association.Strong associations. Aggregation is the relationship between the whole and the individual.For example, the relationship between automobile and engine, tire, and other parts is the relationship between the whole and the individual. Like the association relationship, the aggregation relationship is also implemented through instance variables. However, the two classes involved in the Association are at the same level, while in the aggregation relationship, the two classes are at an unequal level, one representing the whole, and the other representing the part.
• A composition relationship is a type of association.Stronger than aggregation. It requires that the object representing the whole in a common aggregation relationship is responsible for representing the lifecycle of some objects, and the composite relationship cannot be shared.Objects that represent the whole need to be responsible for keeping part of the objects and surviving. In some cases, the objects that represent part of the objects are wiped out. 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, some objects can only be combined with one object at a time, and the latter is exclusive to the lifecycle. The same as the overall lifecycle.

-- From Java object-oriented programming, by Sun weiqin

The relationshipCoupling DegreeIn turn (the concept of coupling degree will be discussed in detail later. Here we can temporarily understand the extent to which a class will affect other classes when a change occurs, the smaller the impact, the weaker the coupling. The greater the impact, the stronger the coupling ). As we know by definition, dependency is actually a weak Association, aggregation is a strong association, and combination is a stronger association, in general cases, these four relationships are actually associated.

The dependency is well differentiated. It is the weakest type of coupling. in Java, it is represented as a local variable, a method parameter, or a call to a static method, as shown in the following example: the driver class depends on the car class. The three methods of the driver demonstrate three different forms of dependency.

Class car {public static void run () {system. out. println ("the car is running");} class driver {// The dependency between public void drive1 (car) {car. run () ;}// use a local variable to create a dependency. Public void drive2 () {car = new car (); car. run ();} // use a static variable to create a dependency. Public void drive3 () {car. run ();}}

Associations are generally implemented using member variables in Java, and sometimes in the form of method parameters. In the example of using driver and car, you can use method parameters to represent dependencies or associations. After all, we cannot express semantics too accurately in the program. In this example, use the member variable to express this meaning: The car is my own, and I "own" the car. The usage parameters indicate that a car is not mine. I am just a driver. If someone else gives me a car, I will drive it. I will use it.

Class driver {// use the member variable form to associate car mycar; Public void drive () {mycar. run ();}... // use method parameters to Associate Public void drive (car) {car. run ();}}

Aggregation is a strong association. Java generally uses the form of member variables. There is an overall and partial relationship between objects. For example, in the previous example

Class driver {// use the member variable form to implement the aggregation relationship car mycar; Public void drive () {mycar. Run ();}}

Let us assume that the above Code has the following semantics: a car is a private car and a part of the driver's property. The same Code indicates the aggregation relationship. Generally, the setter method is used to assign values to member variables.

Assume that a car is a required property of a driver. To become a driver, you must first have a car. If the car is gone, the driver does not want to live. And if the driver doesn't do the driver, the car will be broken, and no one else wants to use it. It indicates the composite relationship. Generally, constructor is often used to initialize a composite relationship. For example, in the previous example, a constructor with car as the parameter is added.

public Driver(Car car){mycar = car;}

Therefore, association, aggregation, and combination can only be determined by combining semantics and context. Instead, only a piece of code is provided to let us determine whether Association, aggregation, or combination, it cannot be judged.

From: http://blog.csdn.net/zhengzhb/article/details/7190158

When learning object-oriented design object relationships, the differences between dependency, association, aggregation, and combination are confusing. In particular, the last three types only have differences in semantics. Semantics refers to context and specific scenarios. Their Expressions in programming languages are basically the same, but they are basically the same and not the same. This is in my previous blogRelationship between classes in Design PatternsAs mentioned in, the following describes in detail how to accurately reflect dependency, association, aggregation, and combination in Java.

First, let's take a look at the definition of these four relationships in the book:

• Dependency relationships are links between classes. Dependency indicates that one class depends on the definition of another class. For example, a person can buy a car or a house. The person class depends on the definition of the car and house classes, because the person class references car and house. Different from associations, the person class does not have the attributes of the car and house types. The car and house instances are transmitted to the buy () method as parameters.In general, dependency is embodied in the local variables, method parameters, or static method calls in Java.
• Association is a join between a class and a class. It allows a class to know the attributes and methods of another class.The association can be bidirectional or unidirectional.In Java, associations are generally implemented using member variables.
• Aggregation is a type of association.Strong associations. Aggregation is the relationship between the whole and the individual.For example, the relationship between automobile and engine, tire, and other parts is the relationship between the whole and the individual. Like the association relationship, the aggregation relationship is also implemented through instance variables. However, the two classes involved in the Association are at the same level, while in the aggregation relationship, the two classes are at an unequal level, one representing the whole, and the other representing the part.
• A composition relationship is a type of association.Stronger than aggregation. It requires that the object representing the whole in a common aggregation relationship is responsible for representing the lifecycle of some objects, and the composite relationship cannot be shared.Objects that represent the whole need to be responsible for keeping part of the objects and surviving. In some cases, the objects that represent part of the objects are wiped out. 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, some objects can only be combined with one object at a time, and the latter is exclusive to the lifecycle. The same as the overall lifecycle.

-- From Java object-oriented programming, by Sun weiqin

The relationshipCoupling DegreeIn turn (the concept of coupling degree will be discussed in detail later. Here we can temporarily understand the extent to which a class will affect other classes when a change occurs, the smaller the impact, the weaker the coupling. The greater the impact, the stronger the coupling ). As we know by definition, dependency is actually a weak Association, aggregation is a strong association, and combination is a stronger association, in general cases, these four relationships are actually associated.

The dependency is well differentiated. It is the weakest type of coupling. in Java, it is represented as a local variable, a method parameter, or a call to a static method, as shown in the following example: the driver class depends on the car class. The three methods of the driver demonstrate three different forms of dependency.

Class car {public static void run () {system. out. println ("the car is running");} class driver {// The dependency between public void drive1 (car) {car. run () ;}// use a local variable to create a dependency. Public void drive2 () {car = new car (); car. run ();} // use a static variable to create a dependency. Public void drive3 () {car. run ();}}

Associations are generally implemented using member variables in Java, and sometimes in the form of method parameters. In the example of using driver and car, you can use method parameters to represent dependencies or associations. After all, we cannot express semantics too accurately in the program. In this example, use the member variable to express this meaning: The car is my own, and I "own" the car. The usage parameters indicate that a car is not mine. I am just a driver. If someone else gives me a car, I will drive it. I will use it.

Class driver {// use the member variable form to associate car mycar; Public void drive () {mycar. run ();}... // use method parameters to Associate Public void drive (car) {car. run ();}}

Aggregation is a strong association. Java generally uses the form of member variables. There is an overall and partial relationship between objects. For example, in the previous example

Class driver {// use the member variable form to implement the aggregation relationship car mycar; Public void drive () {mycar. Run ();}}

Let us assume that the above Code has the following semantics: a car is a private car and a part of the driver's property. The same Code indicates the aggregation relationship. Generally, the setter method is used to assign values to member variables.

Assume that a car is a required property of a driver. To become a driver, you must first have a car. If the car is gone, the driver does not want to live. And if the driver doesn't do the driver, the car will be broken, and no one else wants to use it. It indicates the composite relationship. Generally, constructor is often used to initialize a composite relationship. For example, in the previous example, a constructor with car as the parameter is added.

public Driver(Car car){mycar = car;}

Therefore, association, aggregation, and combination can only be determined by combining semantics and context. Instead, only a piece of code is provided to let us determine whether Association, aggregation, or combination, it cannot be judged.

From: http://blog.csdn.net/zhengzhb/article/details/7190158