C'est un problème que je suis confronté à beaucoup de fois où je concevons une nouvelle application. J'utiliserai un exemple de problème pour expliquer cela.
J'écris un jeu simple, je souhaite donc tenir une liste de joueurs. J'ai peu d'options ... p>
class Game {
private PlayerList playerList;
public Game(PlayerList list) {
this.list = list;
}
public PlayerList getPlayerList() {
return playerList;
}
}
3 Réponses :
L'idée de l'injection de dépendance est que le nom indique d'injecter des dépendances. Donc, quel que soit l'objet dont l'objet doit savoir sur la liste des joueurs sera injecté avec elle. Habituellement, il est très logique d'utiliser l'injection de dépendance aussi largement que possible avant de passer à la recherche de dépendance ou à un autre mécanisme. Cela permettra également d'étendre le jeu plus tard pour avoir différentes listes de joueurs pour différents niveaux ou une extension que vous pourriez penser.
k, mais que devriez-vous faire lorsque je veux utiliser une instance de liste des joueurs quelque part ailleurs?
Vous l'injecteriez à nouveau. Un cadre tel que le printemps (à condition que vous programmez Java) facilitera cela beaucoup plus facilement pour vous. Tout ce qui n'est pas un service ou un singleton lui-même et ne peut donc pas être raisonnablement injecté avec la liste des joueurs qui seront créés par une sorte d'usine qui peut très bien être injectée avec la liste des joueurs et peut le transmettre avec les objets qu'il crée. Toutefois, si vous finissez par injecter votre liste de player dans chaque objet, vous devez avoir une deuxième réflexion sur votre conception, en particulier l'encapsulation et la cachette d'informations.
Si vous avez besoin de playerlist en dehors du jeu, le jeu est peut-être la mauvaise classe pour cela? Si un autre objet a besoin de playerlist, ils doivent également avoir la liste injectée également, soit peut-être pourriez-vous déplacer la liste sur cette classe au lieu de la classe de jeu.
Si vous avez des vies différentes pour le jeu, la playerlist et d'autres classes, vous envisagez également d'utiliser une usine pour les regrouper. Vérifiez cette Article de blog de test Google pour plus de détails .
1) Peut-être que le jeu est la mauvaise classe pour cela, mais toujours si je mets dans une autre classe, le problème est toujours là.Parce que je ne peux pas l'utiliser dans la classe de jeu. 2) Passer la liste de player à toute la classe requise n'a pas de sens, sinon ils sont fabriqués dans la classe d'usine de Deffrent.
C'est pourquoi les conteneurs di gèrent le cycle de vie. Laissez la liste de player être un singleton en termes de cycle de vie du conteneur. Vous donne une vérification complète des composants et laissez le conteneur (pas vous) les mains sale.