Global State and Singletons Dependency injection

Question

this is a problem i face lot of times when i am designing a new app i'll use a sample problem to explain this

think i am writing simple game.so i want to hold a list of players. i have few options..

1.use a static field in some class

private  static ArrayList<Player> players = new ArrayList<Integer>();  
public Player getPlayer(int i){
    return players.get(i);
}

but this a global state

2.or i can use a singleton

class PlayerList{
    private PlayerList instance;
    private PlayerList(){...}
    public PlayerList getInstance() {
        if(instance==null){
            ...
        }
        return instance;
    } 
 }

but this is bad because it's a singleton

3.Dependency injection

class Game {
    private PlayerList playerList;
    public Game(PlayerList list) {
        this.list = list;
    }
    public PlayerList getPlayerList() {
        return playerList;
    }
}

this seems good but it's not, if any object outside Game need to look at PlayerList (which is the usual case) i have to use one of the above methods to make the Game class available globally. so I just add another layer to the problem. didn't actually solve anything.

what is the optimum solution ? (currently i use Singleton approach)

Answer 1

Wait, why are Singletons bad? I love the Singleton. But only once.

Answer 2

The idea behind dependency injection is as the name states to inject dependencies. So whatever object needs to know about the player list will be injected with it. Usually, it makes a lot of sense to use dependency injection as extensively as possible before switching to dependency lookup or some other mechanism. This will also make it possible to extend the game later to have different player lists for different levels or whatever extension you might think about.

Answer 3

If you need PlayerList outside of Game, maybe Game is the wrong class for this? If any other object needs PlayerList, either they need to have the List injected as well, or maybe you should move the list to this class instead of the Game class.

If you have different lifetimes for Game, PlayerList and other Classes, maybe also consider using a Factory to group them. Check this Google Testing Blog article for details.

Answer 4

That's why DI Containers manage lifecycle. Let the Playerlist be a singleton in terms of container lifecycle. Gives you full testability of components and let's the container (not you) get its hands dirty.