8

I am currently creating a big project, and as such I would like to have everything worked out very well and as efficient as possible.

In my project, I have a class called Teams, which contains a HashMap(Integer, Team) of Team objects. Each instance of Team has a unique ID (integer).

There is also an object called Player. Each instance of Player can be assigned to a Team (but not always).

Now, I wonder what the best approach would be to know what Team a Player is assigned to:

-> Store the ID of the team in Player (private int team), this ID is then used to get the Team from the HashMap in Teams.

-> Store a reference to the Team in Player (private Team team)

Does anyone know which is better, and what the most important pro's, con's and dangers are of each?

Thanks!

Insdeath
  • 93
  • 5
  • 1
    It depends entirely on your usecase. Rather than designing classes in isolation, try and design for vertical slices of features. – leonm Sep 29 '11 at 11:12

5 Answers5

8

Use private Team team! Other classes should not need to know the ID of an object unless there is a good reason. Don't implement a Database structure in Java. Java is designed to be Object-based, use it that way.

There are a couple additional reasons you should hold the Team instance:

  1. We can assume that your Player will need to access the Team object. It is better to have the instance rather than having to do a lookup.
  2. If you hold onto IDs instead of instances, there might not be any reference to an object being held and it could be garbage collected. I know that probably won't happen in your case since you hold all Teams in a Map, but it is still a risk and therefore should be avoided.
John B
  • 32,493
  • 6
  • 77
  • 98
  • Thanks for the info. I have just one more question: how much memory does a reference to an object take? – Insdeath Sep 29 '11 at 11:14
  • http://stackoverflow.com/questions/4474114/java-how-much-memory-a-reference-implies – stivlo Sep 29 '11 at 11:20
  • @lnsdeath Not enough to worry about - dont worry about performance details like that at the moment. You'll know if you need to later! – Michael Berry Sep 29 '11 at 11:24
0

Obviously it's impossible to say for certain here without knowing the context in which it'll be used - but from a code design perspective, the "natural" expectancy is that a team contains players, so it's the team that would reference the player objects, not the other way around.

If you start messing around with IDs and need to store large numbers of different objects, it sounds like you're after more of a database, in which case look at something like HSQLDB if you don't want to step out of Java.

Michael Berry
  • 70,193
  • 21
  • 157
  • 216
  • I would think it would need to be a two-way connect. Team would hold a list of Players and Player would hold the Team. I would want to easily determine how many players are on a team and which team a player is on. – John B Sep 29 '11 at 11:18
0

The potential danger with using the object reference as the key in a HashMap (or any Map) is that it can, if done improperly, become a memory leak.

An object will not be garbage collected if there are still references to it. If used as a key in a Map, that is considered a reference to that object.

You can get around this using WeakReference.

In the situation you describe you should probably be using the objects as keys, but be wary of the above conditions.

Charles Goodwin
  • 6,402
  • 3
  • 34
  • 63
0

private Team team is the way to go between the two approaches you mention. If you store the Id , what will happen if the HashMap is updated along ? This is creating unnecessary dependemcies.

Bhaskar
  • 7,443
  • 5
  • 39
  • 51
-1

You using database? If so, store the ID of the team in player, or else I suggest that you store the reference of the team.

Vince.Wu
  • 870
  • 1
  • 10
  • 17
  • -1 Disagree. Just because there is a DB in the background and the table is using an ID is no reason to use an ID in the object. There are plenty of ORM solutions (Hibernate) that make this easy. – John B Sep 29 '11 at 11:16
  • So, I've found that what I said before is not so "right", and, yes, it depends... – Vince.Wu Sep 29 '11 at 12:25