Two Laptop Bag
The moose likes OO, Patterns, UML and Refactoring and the fly likes Object relationships Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Object relationships" Watch "Object relationships" New topic

Object relationships

saurav sarkar
Ranch Hand

Joined: Jan 07, 2007
Posts: 180

Hi All,

I am trying to get the exact defintion with examples for the Object relationships.

In OOPs all the Objects need to communicate with each other otherwise as said standing alone does not help, its a team game

I have 3 type of relations with me.I have found some disagreement on this.
Some people i have encountered they say Aggregation and Composition are special type of Association.Whereas other sphere of Intellegentsia go for the three are different.

I am somehow convinced by the later one.

Association:- When an Class A has connection to Class B by just having a reference to Class B.Where Class A's behaviour is not to create an Object of B type.That is assocaiton where it just associates with B.

Aggregatation:- In this case Class A has a behaviour (method) which created an instance of Class B i.e. Class A aggregates Class B.

Composition:- This relationship is when Class A fully controls the lifecycle of Class B. i.e. Class A creates Class B and Destroys Class B as its behaviour.

I would love to hear thoughts of experts here on this topic.


Be Objectively Oriented.Explore the power of OOPs.
My Blog, Eclipse EMF Query committer.
Peer Reynders

Joined: Aug 19, 2005
Posts: 2933
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This may be a "grumpy old man" point of view, but how much does the distinction matter? I guess it really gets down to communication. We create diagrams with these decorations or a document with these words to communicate something. The state of understanding on these three terms is not good enough that I'd trust all readers will get the same information from it. I'd add a paragraph somewhere to clarify just what I mean by the terms and how it applies to this particular design.

The FAQ noted that this is less important in garbage collected languages like Java than others with explicit destructors. It is interesting that if you think you have composition where A controls the life cycle of B, and you let a reference to B slip out to other classes, A no longer controls the life cycle. Would composition on a design diagram make you think of keeping B completely private?

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Scott Ambler
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
In The Object Primer, I go into this issue in a bit of detail. Here are some thoughts:
1. It doesn't really matter in the long run. The real goal is to build high quality software which meets the actual needs of your stakeholders, not to produce pretty diagrams.
2. Composition is a stricter form of aggregation.
3. Aggregation is a stricter form of association.
4. It really doesn't matter in the short run. So, the real issue here is whether you need to include a diamond on one end of the association line, and if so whether or not it should be filled in?

- Scott

<a href="" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
I agree. Here's the link:
subject: Object relationships
It's not a secret anymore!