J'examine le code avec beaucoup de déclarations telles que ceci: Je voudrais attendre quelque chose comme P> private SomeInterface x;
@Inject
public Consumer(SomeInterface x){ // constructor
this.x = x;
}
4 Réponses :
Premier exemple: x = locator.getinstance (individuinterface.class) ressemble à un modèle de localisateur de service et HTTP : //blog.ploeh.dk/2010/02/03/servicelocatorisanantiipattern.aspx Vérifiez cet article, il indique que le localisateur de service est un anti-motif et doit être évité
et pour la deuxième utilisation, tout va bien, j'aime l'injection du constructeur, sa mise en œuvre fine lisse. Mais je voudrais ne pas utiliser d'attributs (Annotanitons en Java?) Cause Chaque fois que je voudrais changer de conteneur di conteneur j'utilise et je ne veux pas supprimer un attribut de toutes les classes.
@Inject est normalisé en Java par JSR-330 < / a>
@deamon Je pensais que c'était juste une annotation de Di de Bob de Bob. Je ne savais pas que c'était accepté comme étalonneur de langue. Merci pour l'info.
Aussi: Contexts et injection de dépendance pour Java (CDI) défini dans JSR 299 , JSR 346 , et JSR 365 . Maintenant entretenu chez Jakarta.ee comme Contextes de Jakarta et injection de dépendance .
Martin Fowler a écrit un Article sur les locateurs de Di Versus :
pour di:
- plus facile de déterminer quelles dépendances ont un composant - regarder constructeur.
- composant n'a pas de dépendance sur le localisateur de services, donc il n'y a pas de problème si le composant est utilisé avec un cadre différent.
- di peut rendre les tests plus faciles, mais un bon mécanisme de localisation de services sera Faire de l'éciple également réalisable
contre di:
- plus difficile à déboguer et à comprendre.
- composant ne peut pas demander des services supplémentaires de l'injecteur une fois qu'il avait été configuré.
Personnellement, je ne pense pas que rien ne soit intrinsèquement mauvais avec la première approche basée sur le localisateur - je suppose que di standardise cela cependant, donc si c'est disponible, je l'utiliserais. Toutes les bonnes idées ont tendance à se retrouver comme des cadres à un moment donné, cela a donc ce qui s'est passé ici. De plus, avec DI, vous pouvez profiter d'autres annotations, étendues, etc. sans avoir à rouler votre propre code. Et moins le code sur mesure, votre projet utilise le meilleur IMO. Je laisserai le dernier mot à Fowler cependant:
Le choix entre localisateur de service et L'injection de dépendance est moins importante que le principe de séparation Configuration du service à partir de l'utilisation de services dans une application.
Il n'y a rien de "faux" comme tel avec le modèle de localisateur de service,
Dans ce cas particulier, le seul argument majeur en faveur de DI serait la testabilité.
Sans aucun doute, DI permet de meilleurs tests unitaires. La méthode Static Getinstance sur le locator rend plus difficile la test de test isolément.
Il y a plus que seuls les tests unitaires. Mark Seemann a décrit cela très clairement: blog.ploeh.dk/2010/02/ 03 / ServiceLocatorisanantiPattern.aspx .
Voulu éviter ces types de discussions philosophiques :) "Anti-motif" est une déclaration sur une instruction excessive d'IMHO. Je suis personnellement aussi en faveur de DI, mais je n'irais pas aussi loin que pour le marquer comme un modèle anti-modèle lors d'un examen de code.
J'ai introduit le CIO (sous la forme du modèle de localisateur de services) quelques années de retour sur un projet pour permettre à cette équipe de commencer à écrire des tests. Ce fut un bon départ de ne pas pouvoir tester du tout. Mais maintenant, plus de deux ans plus tard, avoir ce modèle sur place au lieu d'utiliser DI est une vraie douleur réelle. Donc pour moi que ce n'est plus philosophique. Je suis allé là-bas, je l'ai expérimenté, et tout était de ma faute. De nos jours, j'essaie de crier au fur et à mesure que je peux pour aider les autres à faire de l'erreur que j'ai faite.
localisateur de service Modèle utilise un registre central appelé "localisateur de service" qui retourne sur demande les informations nécessaires pour effectuer une certaine tâche.
Ce sont les pires côtés du modèle de conception de localisateur de service:
Les choses placées dans le registre sont effectivement des boîtes noires avec
considère le reste du système. Cela rend plus difficile de détecter et
récupérer de leurs erreurs et peut rendre le système dans son ensemble moins
fiable.
Le registre doit être unique, qui peut en faire un goulot d'étranglement pour Le registre peut être une vulnérabilité de sécurité sérieuse, car elle
permet aux étrangers d'injecter du code directement dans une application.
ne peut pas réussir les dépendances par constructeur (comme nous le faisons dans di motif) et dure à un appareil-test
Et je mon avis à l'aide du modèle de localisateur de services n'est acceptable que sur le niveau supérieur de votre application lorsque votre localisateur de service ne changera probablement pas
Applications simultanées.
Steveschols.wordpress.com/2012 / 05/14 / ...