* Return a list of the players that are on this
List<? extends Player> getPlayerList();
* Add a player to the team.
void addPlayer(Player toAdd);
* Remove a player from the team.
void removePlayer(Player toRemove);
This interface allows us to get the name of the team, assign a player to the team, remove a
player from the team, and get a list of all of the players who are currently on the team. Note
that we are using a parameterized list that allows us to get back not just a Player object but
any object that extends the Player interface; we will talk more about parameterized types in
The reason we are talking about these interfaces is that we now have an object (the Team ob-
ject) that will contain references to Player objects. And because we now have a way to store
references to an object, we also have a way to defeat the garbage collector. All we have to do
to get a memory leak is to forget to remove a Player object from a Team when, say, a play-
er retires (rather than being moved to a different team). We might not use that Player object
anymore, but there will still be a reference to the object that can be traced and that will keep
the garbage collector from reclaiming the space used by the object.
A memory leak in this case is not very likely, but anyone using Java needs to know that any
compilation of references is a potential area for a memory leak. If there are numerous places
where a reference to an object might be stored, we have to make sure that all of those referen-
ces are deleted when we are done with the object. If any one of them remains, the object will
remain, taking up the space that could otherwise be reused. So even though garbage collection
frees us from having to think about when the memory taken up by an object can be reclaimed,
we still need to be careful and make sure that when we are done with an object, we clear the
references in our program to allow the garbage collector to do its work.