• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is there a useful distinction between composition and aggregation?

 
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was reading a book by Robert Martin and he stated that composition is not that useful in Java but is in C++. The distinction he draws is very nitpicky for general use, in my opinion.

So is it useful in everyday programming to draw this distinction or is it an unnecessary detail, except within more technical discussions of language concepts and design?
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What was the distinction? Why is it not useful in Java?
 
Rusty Shackleford
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The main distinction was that composition made use of deep copies and is a special from of aggregation. Aggregation has a "whole part" relationship.

I have always used the terms interchangably, and was just wondering if this is proper.

The discussion was in terms of UML.
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a small, but very important difference between agregation and composition. They both are whole-part relationships, but composition implies additional constraints...

The Unified Modeling Language Reference Manual says:


"A composite is an agregate with the additional constraints that an object may be part of only one composite and that the composite object has responsability for the disposition of all its parts, that is, for their creation and destruction".


[ October 10, 2006: Message edited by: Edwin Dalorzo ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wouldn't that be a distinction between aggregation and composition? I'm wondering why he thinks it's not useful in Java but is in C++.
 
Rusty Shackleford
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps that objects in Java doesn't require explicit destructors and deep copies are rarely used?
[ October 10, 2006: Message edited by: Rusty Shackleford ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay, I can see that but I don't think that makes composition not useful in Java. I use composition frequently especially when dealing with mutable classes and all the more so when the aforementioned mutable classes are used by an immutable class. Consider a class that should be immutable but relies on mutable classes for it's implementation. Either the implementation of the mutable classes must be inlined, or an immutable version of the classes must be created, or you have to use composition.

Perhaps what I commonly refer to as composition doesn't quite meet the definition, but I'm fairly sure it meets the spirit of it. If I have a class that is to be immutable and makes use of three mutable classes and one immutable class then is it composition if the immutable class has a life outside our class? The three mutable classes would be created internally and never exposed, the one immutabele class might be exposed or accepted as a parameter to a constructor. Is this still composition?

Maybe not, but it's nonetheless not uncommon to see all of the classes being mutable in which case all of them are created internally and never exposed. I could go through the trouble of creating the immutable class too, but what would the point of that be? The immutable class isn't going to reference back to my class and a client might be passing one instance around to save memory or improve performance, so forcing it to be created internally for the academic purpose of technically being composition would be silly.

The point is I think composition can be used often and for good reason. It's possible, however, that it's not often truly composition but instead something terribly close that doesn't quite meet the definition.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ken Blair:
Is this still composition?



As far as I can tell, it is *more* than composition. Composition, as defined by UML (and as explained by Uncle Bob) doesn't hold an object from being exposed to the outside. In fact it doesn't even require that it is created and destroyed by the same parent object, as far as I know.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


As far as I can tell, it is *more* than composition. Composition, as defined by UML (and as explained by Uncle Bob) doesn't hold an object from being exposed to the outside. In fact it doesn't even require that it is created and destroyed by the same parent object, as far as I know.



Why? With a composite are the attributes not purely contained within the composite? If they have a life outside the composite then isn't that aggregation? I don't see how that would work, if the attribute is exposed then it's destruction by the composite would be pretty dangerous wouldn't it? What happens to the client that was using that exposed attribute?

Particularly in Java I think the only way to have composition is to not expose the attribute. If we expose it then it's lifetime is no longer that of the composite because it has references outside of the composite. This of course could be very bad especially if the composite was implemented with the assumption that it's attributes lifetime's would be the same as the composite. Take an inner class which implicitly has a reference back to the enclosing instance. What happens if it's added to one of the composite's attributes, which is then exposed. It's lifetime is no longer controlled by the composite and consequently neither is the lifetime of the inner class. That could very easily prevent the composite itself from being collected and along with it the other attributes.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The UML Reference Manual in the section Encyclopedia of Terms says:


Composition

A form of agregation with strong ownership and coincident lifetime of parts by the whole. A part may belong only to one composite. Parts with non-fixed multiplicity may be created after the composite itselt. But once created, they live and die with it (that is, they share lifetimes). Such parts can also be explicitly removed before the death of the composite. Composition may be recursive.

Semantics
There is a strong form of aggregation called composition. A composite is an agregate association with the additional constraints that an object may be part of only one composite at a time and that the composite object has sole responsibility for the disposition of all its parts. As a consequence of the first constraint, the set of all composition relationships (over all associations with the composition property) forms a forest of trees made of objects and composition links. A composited part may not be shared by two composite objects. This accords with the normal intuition of physical composition parts (one part cannot be a direct part of two objects, although it can indirectly be part of multiple objects at different levels of granularity in the tree).

By having responsibility for the disposition of its parts, we mean that the composite is responsible for their creation and destruction. In implementation terms, it is responsible fro their memory allocation. During its instantiation, a composite must ensure that all its parts have been instantiated and correctly attached to it. It can create a part itself or it can assume responsibility for an existing part. But during the life of the composite, not other object can have responsibility for it. This means that the behavior for a composite class can be designed with knowledge that no other class will destroy or deallocate the parts. A composite may add additional parts during its life (if multiplicieties permit), provided it assumes sole responsibility for them. It may remove parts, provided the multiplicities permit and responsibilites for them is assumed by another object. If the composition is destroyed, it must either destroy all its parts or else give responsibility for them to other objects.

This definition of composition works well with garbage collection. If the composite itself is destroyed, the only pointer to the part is destroyed and the part becomes inaccessible and subject to garbage collection.

An object may be part of only one composite at a time. This does not preclude a class from being a composite part of more than one class at different times or in different instances, but only one composition link must exist at one time for one object.



I hope this helps to set this clear.
[ October 12, 2006: Message edited by: Edwin Dalorzo ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Edwin Dalorzo:

I hope this helps to set this clear.



Not really. For example, "but only one composition link must exist at one time for one object" doesn't say whether there can be non-composition links of an object beside the one composition link.

The garbage collection comment seems to imply that not. But I'm not totally sure.
 
Rusty Shackleford
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for all the replies. It is a very interesting conversation. I am even more of the opinion that the distinction is normally not worth bothering about.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Not really. For example, "but only one composition link must exist at one time for one object" doesn't say whether there can be non-composition links of an object beside the one composition link.



I am not sure,Ilja, if I understand what you mean by non-composition links. Do you mean like assigning a composite part to a local variable, for example?

In this regard I think the UML specification is not that clear, you are right.

What do you think of this way of reasoning?

If my composite becomes elegible for GC now, do its parts become elegible for GC either?

If the answer is yes, then I would say it is composition, if not, then I would say it is not.

Whether what you said, Ilja, is what I understood or not, I do believe that assigning a reference of the composite part outside the composite itself may potentially be breaking the concept of composition, if during the method execution the "whole" became elegible for GC and its "part" did not. Or if its part survived the scope of the method execution, maybe as a return reference or as a parameter reference; since the "whole" no longer would have the control over the destruction of the "part" object.

I do not know if you would consider this too conservative, liberals might believe I am exagerated.
[ October 12, 2006: Message edited by: Edwin Dalorzo ]
 
But how did the elephant get like that? What did you do? I think all we can do now is read this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic