Compostion, aggregation & association

Question

Hello All,
I have to clear a concept to myself, so am asking this question to you guyz. Plz don't hesitate to give me your clear views over it.
Lets consider the following three relationships:
a. Car ------ Engine     (Composition)
b. Car ------ Stereo     (Aggregation)
c. Car ------ Driver     (Association)I just can't make the proper symbols of relationships so i have mentioned the said relationships in brackets. ok, now I have just 2 questions:
1- To implement physically, will there be any difference in the implementation of b & c relationships ?
2- What should be the difference in class design of a & b relationships so that we could easily understand the concept of "Composition" and "Aggregation" ? (I mean how a developer enforce the idea that 'Engine' object should be constructed when 'Car' object is going in the process of being constructed)
One thing: i need some detailed and full of examples discussion on second question. I hope you people will like this thread and make it as healthy as possible. Will wait for some serious thoughts over it.
thanks.

Answer 1

UML 1.5 section 2.5.4.1has a reasonable description of aggregate and composite:
An association may represent an aggregation (i.e., a whole/part relationship). In this case, the association-end attached to the whole element is designated, and the other association-end of the association represents the parts of the aggregation. Only binary associations may be aggregations. Composite aggregation is a strong form of aggregation, which requires that a part instance be included in at most one composite at a time and that the composite object has sole responsibility for the disposition of its parts. This means that the composite object is responsible for the creation and destruction of the parts. In implementation terms, it is responsible for their memory allocation. If a composite object is destroyed, it must destroy all of its parts. It may remove a part and give it to another composite object, which then assumes responsibility for it. If the multiplicity from a part to composite is zero-to-one, the composite may remove the part, and the part may assume responsibility for itself, otherwise it may not live apart from a composite.
WRT your questions:
1- Possibly. You can represent the ends of associations as references in the classes:class Car {
  Engine engine;
  Stereo stereo;
  Driver driver;
class Driver {
  Car car;
}Or you can represent association relations as separate link objects:class Car {
  Engine engine;
  Stereo stereo;
class Driver {
class CarDriverLink {
  Car car;
  Driver driver;
}The second case is useful when additional information about the link is required (say the car pool manager needs to keep a list of authorised associations), or for lazy access. This is called reification.
It is also perfectly valid to maintain redundant information, so that the ends of the link also have references to the link, or the opposite end, for navigation purposes.
It isn't as common to reify aggregations, as this alters the lifecycle semantics of ownership, unless the reified relation link is owned by the aggregate, rather than a third party:class Car {
  List <CarEngineLink> engines;
class CarEngineLink {
  Car car;
  Engine engine;
}So in the basic case, there isn't a difference, but in more complex aggregations the ownership semantics can be made explicit.
2- As the JVM takes care of freeing memory, then it is no longer the aggregate's resposibility to deallocate the memory for the part. However, if a reference to the part is kept outside of the aggregate beyond the aggregate's lifecycle, then the relationship is one of aggreagation not composition. In other words, the structural implementation is the same, but the behavioural implementation will differ.
If a car has to have one engine and that engine cannot be changed in the lifecycle of the car, you can use final to enforce the constraint and throw a null pointer exception if null is passed in; however, that is a cardinality and mutability constraint, which is orthogonal to composition/aggregation.
Pete