Global de Estado y simple inyección de dependencias

Question

este es un problema que enfrento muchas veces, cuando estoy diseñando una nueva aplicación Voy a usar un problema de ejemplo para explicar este

piensan que estoy escribiendo game.so sencilla quiero para mantener una lista de jugadores. tengo pocas opciones ..

1.Utilice un campo estático de alguna clase

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

pero esto un estado global

2.O i puede utilizar un producto único

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

pero esto es malo porque es un producto único

inyección 3.Dependency

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

esto parece buena, pero no lo es, si cualquier objeto fuera de juego necesita mirar playerlist (que es el caso habitual) tengo que usar uno de los métodos anteriores para hacer que la clase Juego esté disponible globalmente. así que simplemente agrego otra capa al problema. en realidad no resolvió nada.

¿cuál es la solución óptima? (actualmente uso el enfoque Singleton)

Answer 1

La idea detrás de la inyección de dependencia es como el nombre indica para inyectar dependencias. Entonces cualquier objeto que necesite saber sobre la lista de jugadores será inyectado con él. Por lo general, tiene mucho sentido utilizar la inyección de dependencia lo más extensamente posible antes de cambiar a la búsqueda de dependencia u otro mecanismo. Esto también hará posible extender el juego más tarde para tener listas de jugadores diferentes para diferentes niveles o cualquier extensión en la que puedas pensar.

Answer 2

Si necesita PlayerList fuera del juego, ¿tal vez el juego es la clase equivocada para esto? Si algún otro objeto necesita PlayerList, o bien necesitan que se le inyecte la Lista, o tal vez deberías mover la lista a esta clase en lugar de a la clase Game.

Si tiene diferentes tiempos de vida para Game, PlayerList y otras clases, tal vez también considere usar una fábrica para agruparlos. Compruebe esto Google Testing Blog article para más detalles.

Answer 3

Es por eso que DI Containers administra el ciclo de vida. Deje que Playerlist sea un singleton en términos de ciclo de vida del contenedor. Le da una capacidad de prueba completa de los componentes y permite que el contenedor (no usted) se ensucie las manos.