Composition and Aggregation
hey guys
I have read the previous posts about composition and aggregation. And here is what i have got.
Composition: life time of objects got to be the same. For example there is a composition between carframe and a car. If the car gets destroyed the carframe woulod also get destroyed.
Aggregation: Life times of the objects are not the same, one oject can live even after the other object has been destroyed.
But i seem to get all these things in theory, but when it comes to coding am not able to translate these theories. To be particular i would want someone to help with me how these relationship can be coded
Thanks
K
Hi,
In simple terms:
If you have an array of pointers (in C++) as a member then it is Aggregation.
If you have an array of objects then it is composition.
The memory allocated to the array of pointers will be clreared once the object that contains the array is garbage collected. But the actual location where the pointers were pointing still exists and could be used by other instances or classes.
Where as an array of objects is garbage collected with the values, along with the container object itself.
Thanks, That made a lot of sense but, how can i go about doing the same in Java?ThanksK
> Thanks,
>
> That made a lot of sense but, how can i go about
> doing the same in Java?
Composition, Aggregation and basic associations are all implemented the same in Java, namely a field in one holds a reference to another. The distinction is too subtle to be captured directly in a Java field definition.
Chuck
> If you have an array of pointers (in C++) as a member
> then it is Aggregation. If you have an array of objects then it is
> composition.
Not so fast. A field which is a pointer (or reference) in C++ does not imply aggregation as it may also simply be an association or even a composition implemented differently than you say.
I do agree that a field in C++ that holds an instance of an object (as opposed to a reference or pointer to it) is indeed composition (as its lifecycle is limited to that of the composing instance. However, not all compositions need be constructued in this way.
Don't assume UML constructs directly map to one and only one (or in that matter, to any) construct in a programming language. That is the difference between design and implementation.
Just follow the same rules. For example, if you have a class that creates an object and does not allow a reference to it to escape then that object isn't going to be able to live outside the lifetime of an instance of that class. Similarly if you created a class that had an object passed to it's constructor then obviously that object has a life outside of that class since it was created outside of that class. If your class creates an object and allows a reference to escape, such as passing that object to some other object then once again the possibility for life outside that class exists.
In java aggregation and composition code remains the same. In fact it may not be possible to achieve composition in Java. As can only have reference of another class as a property, which is aggregation.
whereas in Database its easy to differentiate Compostion and Aggregation. ie we can achieve Composition by means of Cascade-all.
> In java aggregation and composition code remains the
> same. In fact it may not be possible to achieve
> composition in Java. As can only have reference of
> another class as a property, which is aggregation.
No. Referencing another class does not make it aggregation. I could easily create a Brain class and a Person class and have each instance of Person create a private instance of Brain. This is composition, not aggregation. The fact that Brain is a different class has nothing to do with it.
> In java aggregation and composition code remains the
> same. In fact it may not be possible to achieve
> composition in Java. As can only have reference of
> another class as a property, which is aggregation.
>
> whereas in Database its easy to differentiate
> Compostion and Aggregation. ie we can achieve
> Composition by means of Cascade-all.
not true.
Inner classes are best used to represent composition relationships in an object model. Therefore, the enclosing instances should always have total control over the enclosed instances.
http://www.onjava.com/pub/a/onjava/excerpt/HardcoreJava_chap06/index.html
can u send the exact different b/w these ones..... where it was really used in java
> Inner classes are best used to represent composition
> relationships in an object model. Therefore, the
> enclosing instances should always have total control
> over the enclosed instances.
Not true. As soon you publish the inner object, you lose all control over it. The only way to have true composition in Java is to never let references to internal objects escape their parent's scope.
Consider the following example :
Car has an engine, chairs, wheel, etc. it is clear that this is composition, because "Car" is composed of engine, chairs wheel and so on. but think about what happens if you want to destroy the car, but reuse its engine, thing that frequently happen when you get your car smashed (didn't happen to be thanks god). Anyway you destroy the car, but it parts stay alive. so the "composed" objects lifetime can exceed the "composer" object lifetime.
I think of composition and aggregation in the following way :
if there is no meaning to the object without its parts (parts of which it is
composed) then it is composition. if there is any meaning for the object without its parts (like empty paragraph (without words) in text, which can be left empty till the wrighter have something to write in) well, then it is aggregation.
