This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Composition Vs Aggregation 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 "Composition Vs Aggregation" Watch "Composition Vs Aggregation" New topic
Author

Composition Vs Aggregation

Saritha Penumudi
Ranch Hand

Joined: Aug 18, 2003
Posts: 147
Hi,

Let us say there are two entities, Airports and Fuel Trucks that are used to fuel Aircraft.

Fuel trucks are assigned to Airports. One Airport can be associated to more than one fuel trucks.

Initially my thinking was, as one fuel truck is associated to only one Airport, that is Airport contains Fuel Trucks.Hence there is an Composition relationship between Airport and Fuel Truck.
Hence In my Airport class, I have collection of Fuel trucks as attribute and I have methods to maintain these Fuel Trucks. That is I have CRUD methods of Fuel Trucks in Airport class.

In this case, in order to get the list of Fuel Trucks, I have to ask Airport class to get the collection.

Now, In the requirements I see that when Fuel Truck is being updated, the user can update the Airport also. That is user is assigning this fuel truck to some other Airport, which clearly states that there is no composition relationship between Airport and Fuel Trucks.

Now, I am confuse to make a decision if there is an Aggregation relationship between Fuel trucks and Airport or it is just a association relationship.

I would appreciate if someone could help me in solving my problem. I wanted to know the correct relationship and where should CRUD methods for Fuel trucks should reside.

I can see these two options:
1. If it is a Aggeration relationship, then I should still have methods to add, delete, update, get Fuel Trucks in Airport class.
2. If it just an assoication relation where I will have a seperate module called FuelTruckMaintenance which would contains these methods.

Your help would be greatly appreciated

Thank you
Saritha
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
There are probably a couple options I can think of. Both have their ups and downs.

First of all, you could continue to have the trucks contained within the airport. However, I expect each truck would have to contain a reference to the airport that it is assigned to. That way, when doing maintenance and you decide to reassign a truck, that truck could tell the airport it's currently assigned to that it should remove it and it could tell the new airport that it's being assigned to that it should add it.

This option should work, but seems sloppy in that both the aiport and the truck know about one another.

Another option would be to introduce a third class: a truck manager. The truck manager might be nothing more than a HashMap (or something similar). For example, maybe the manager uses the airports as keys and hold Lists of trucks as values. Therefore, any airport could get a list of the trucks currently assigned to it by sending a reference to itself to the truck manager.

Going the other way, if a truck were to be reassigned, the truck need not know about the airport - it only needs to know about the truck manager, which makes more sense (to me, anyway). The truck could tell it's manager that it needs to be reassigned and the truck manager could take care of moving the truck from one list to another.

This solution seems a little cleaner to me, but it doesn't involve the introduction of another object.

So those are the first couple ideas that hit me, but there may certainly be better options out there.


SCJP Tipline, etc.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Why do you care? The real issue is that there is a relationship between trucks and airports that you seem to have captured.

How important is it, really, that one end of the line has a diamond on it or not? Or if the diamond is hollow (aggregation), or filled in (composition)?

I have some aggregation and composition guidelines posted at http://www.agilemodeling.com/style/classDiagram.htm#_Toc1020019 which you might find of value. They're excerpted from Elements of UML Style (www.ambysoft.com/elementsUMLStyle.html).

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
 
GeeCON Prague 2014
 
subject: Composition Vs Aggregation