问题
I have read a lot of theory regarding object relationshisps, and I am still having difficulty understanding how are association and aggregation seperated from implementaion point of view. In both cases you will have object B as a data member in object A, where it is present there as a reference,(unlike with composition where it exists there by value). So what is the difference between the two cases really? I have read somewhere that some Java gurus consider aggregation a solely abstract concept, a "placebo" case that can not be told apart (from association) from implementation/syntax point of view, is that right or have I missed something?
回答1:
There is normally no difference in the implementation of an aggregation versus an association because their semantic difference is normally not relevant in the code of an app.
An aggregation is a special form of association with the intended meaning of a part-whole-relationship, where the parts of a whole can be shared with other wholes. For instance, we can model an aggregation between the classes DegreeProgram and Course, as shown in the following diagram, since a course is part of a degree program and a course can be shared among two or more degree programs (e.g. an engineering degree could share a C programming course with a computer science degree).
Modeling the special relationship between DegreeProgram and Course in this way conveys some intended meaning, but does not have to be, and is typically not, reflected in the implementation code, which may look as follows:
class DegreeProgram {
private List<Course> courses;
...
}
回答2:
I agree that from the implementation point of view both association and aggregation look the same - like you mentioned, in both cases one of the objects is a data member in the other.
The way I understand this is that the implementation difference that you are asking about does not happen at the level of the object, but rather at the level of the application design:
If by implementation difference you understand the code itself (the way the object is placed within another), then there is no difference.
But if we extend the conversation to how the objects are used within the application, then we need to start looking at whether the objects are self sufficient or not, whether they can serve a unique, independent function or not. It is for you to decide whether this is still implementation
Edit -> additional explanation added below:
I might have not been clear enough - what I meant was that in this case the implementation could be considered on two levels:
the code that represents the object within the class (the field holding the reference to the object)
the wider code (how the object is used in other classes or how the dependencies between objects are represented)
Both of those could be understood as implementation, but on different levels of abstraction - the usage within the class is the same for both Aggregation and Composition, yet the way the object relationships are implemented across multiple classes would differ.
回答3:
To be correct: the UML term aggregation (you probably are referring) is composite aggregation. P. 110 of UML 2.5 says:
composite- Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
In case you mean a shared aggregation, see the same p. 110:
shared- Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
tl;dr
The difference is quite simple. A composite (aggregate) object must be destroyed if the aggregating object says good bye. An associated oject does not care (or the referring object will not try to kill it).
For a shared aggregation: invent your own definition and publish it along with its usage.
来源：https://stackoverflow.com/questions/58476608/the-difference-between-aggregation-and-association-in-implementation