This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
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.
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.