Lorsque vous traitez avec des objets nécessitant des données connues uniquement au moment de l'exécution, tels qu'un nom d'utilisateur et un mot de passe, où l'instanciation d'objet devrait-elle se produire: en utilisant de nouveaux, dans une usine ou dans un conteneur DI?
Par exemple, je pouvais Just ou, je pourrais utiliser une usine: ou, je pourrais utiliser un fournisseur dans un conteneur DI (lequel dans ce cas serait essentiellement une usine de paramètres). [Exemple de code omis.] Il semble que les deux mal utilisent le conteneur DI pour quelque chose de si simple, mais il semble également faux de ne pas l'utiliser au maximum. nouveau un objet une fois que j'ai les données:
4 Réponses :
Pour moi, j'utilise DI pour créer un couplage plus lâche entre des objets. Si vos dépendances d'objet sont très affectées en créant un objet en utilisant de nouveaux, je ne vois pas pourquoi vous ne pouviez pas utiliser la création d'objet DI ou de relais dans une usine. Cela vous donne plus de contrôle et conserve vos classes loosley couplées.
Cela dépend vraiment quand et où vous aurez besoin de cet objet et s'il y aura des dépendances inutiles.
Si vous avez déjà un conteneur DI configuré pour votre application, utilisez cette approche. Sinon, utilisez une méthode d'usine.
Comme toujours, cela dépend, mais en règle générale, une usine statique comme votre deuxième option n'est que rarement une bonne idée.
Dans d'autres cas, le type que vous souhaitez créer peut représenter une abstraction en soi. Si tel est le cas, vous ne pouvez pas utiliser le mot-clé L'utilisation d'une usine abstraite est souvent très précieuse car elle vous permet de composer une instance d'une combinaison de valeurs de temps d'exécution et d'autres dépendances. Voir ici pour plus d'informations.
Utiliser une usine abstraite aide également avec test unitaire car vous pouvez simplement tester que la valeur de retour ou l'état de fin ou tout ce que vous vous souciez d'être lié à la sortie de l'usine abstraite - pour laquelle vous pouvez Fournissez facilement un double test Nouveau ING UP UP up Un objet userCredential semble être un choix équitable car la classe UserCreDentials ressemble à une classe concret autonome et autonome pouvant être entièrement instanciée à tous ses invariants du nom d'utilisateur et de mot de passe. < / p>
nouveau , mais doit utiliser une usine
Je n'avais même pas consciemment pensé à l'usine statique vs abstrait usine. Merci pour le commentaire de l'additif de valeur à cet égard.
Le blog Google test a Un post qui essaie de répondre à cette question . L'idée de base est que vous pouvez classer chacune de vos classes comme une "nouvelle" ou "injectable", et qu'il est correct pour simplement "nouveau" les nouveautables.
Je distingue 2 catégories principales de "Newables":
int , string , datetime , etc.
- Entités comme
CLIENT , COMMANDER , EMPLOYÉ , etcetera. Je pense que votre userCredentials (code> classe est-il sous cette rubrique.
Il est important de réaliser que Newables peut avoir un comportement (testable) . Si vous faites l'erreur de penser que les nouveautables ne devraient pas avoir de comportement ni de tests unitaires, vous vous retrouverez avec le Modèle de domaine anémique anti-motif.
Un effet secondaire d'avoir des "nouveauxbles" avec le comportement est que ce comportement ne peut pas être abstraité dans les tests d'unité de vos injectables. C'est acceptable; Il est normal d'avoir un fort couplage entre votre modèle de domaine et le reste de votre application.
En outre, les nouveaux-plats sont autorisés à connaître les injectables, mais ils ne coopèrent que avec elles de manière transitoire. Par exemple, userCredentials ne doit pas prendre un iUserDatabase comme argument de constructeur. Au lieu de cela, il pourrait y avoir une userCredentials.verify (iuserdatabase) méthode.
EDIT: Je ne suis plus sûr de ce que j'ai écrit ci-dessus. Les entités peuvent également être construites via des usines (injectables) au lieu d'appeler directement leur constructeur. La mise en œuvre de l'usine peut alors injecter des choses dans l'entité.
Votre lien "modèle de domaine anémique" fait référence à l'article «à nouveau ou non neuf».