Est-il normal d'avoir une longue liste d'arguments dans le constructeur d'une classe Presenter?

Question

Avertissement de surcharge d'acronyme s'approchant !!! Je fais TDD et DDD avec un modèle de vue passive MVP et DI. Je me trouve en ajoutant la dépendance après la dépendance au constructeur de ma classe de présentateur pendant que j'écris chaque nouveau test. La plupart sont des objets de domaine. J'utilise des usines pour l'injection de dépendance bien que je vais probablement passer à un conteneur IoC par la suite. Lors de l'utilisation de l'injection de constructeur (en fonction de l'injection de propriété), il est facile de voir où sont vos dépendances. Un grand nombre de dépendances est généralement un indicateur qu'une classe a trop de responsabilités, mais dans le cas d'un présentateur, je ne vois pas comment éviter cela. Je pensais à envelopper tous les objets du domaine dans une seule classe "Domain" qui agirait comme un intermédiaire, mais j'ai l'intuition que je ne ferais que déplacer le problème au lieu de le réparer.

Ai-je raté quelque chose ou est-ce inévitable?

Answer 1

Je n'utilise DI que sur le constructeur si j'ai besoin de quelque chose pour être là dès le départ. Sinon, j'utilise des propriétés et j'ai un chargement paresseux pour les autres éléments. Pour TDD/DI aussi longtemps que vous pouvez injecter l'élément lorsque vous en avez besoin, vous n'avez pas besoin de l'ajouter à votre constructeur.

Je recommande toujours de suivre la loi de Demeter et ne pas suivre le mythe DI de tout doit être dans le constructeur. Misko Hevery (Coach Agile chez Google) le décrit bien sur son blog http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

Answer 2

Souvent, un grand nombre d'arguments d'une méthode (constructeur, fonction, etc.) est une odeur de code. Il peut être difficile de comprendre quels sont les arguments. C'est particulièrement le cas si vous avez un grand nombre d'arguments du même type. Il est très facile pour eux d'être confus ce qui peut introduire des bugs subtils.

Le refactoring est appelé "Introduce Object Parameter". Qu'il s'agisse d'un objet de domaine ou non, il s'agit essentiellement d'un objet de transfert de données qui minimise le nombre de paramètres transmis à une méthode et leur donne un peu plus de contexte.

Answer 3

Avoir un Layer Supertype n'est peut-être pas une mauvaise idée, mais je pense que votre odeur de code pourrait indiquer quelque chose d'autre. Geofflane a mentionné le modèle de refactor, Introduce Parameter Object. Bien que ce soit un bon modèle pour ce genre de problème, je ne suis pas tout à fait sûr que ce soit le bon choix. Question: Pourquoi transmettez-vous des objets de modèle de domaine au constructeur?

Il y a une telle chose que d'avoir trop abstraction. S'il y a une couche de code solide à laquelle vous devriez faire confiance, c'est votre Domain Model. Vous n'avez pas besoin de référencer 3 objets IEntity lorsque vous traitez avec des classes Client, Fournisseur et Produit si celles-ci font partie de votre Modèle de domaine de base et que vous n'avez pas nécessairement besoin de polymorphisme.

Mon conseil: Passez en application et le domaine services. Faites confiance à votre modèle de domaine.

EDIT:

Relire le problème quand il est pas horriblement tard dans la nuit, je me rends compte de votre « classe Domain » est déjà introduire des paramètres objet refactoring et non, en fait, une couche Supertype, comme J'ai pensé à 3h du matin.

Je réalise également que vous devez peut-être référencer les objets Modèle dans le code de l'application, en dehors du Presenter. Peut-être que vous faites une configuration initiale de vos objets Modèle avant de les transmettre au Presenter. Si c'est le cas, votre idée de "classe de domaine" pourrait être meilleure. S'il y a une configuration initiale, en passant à un IoC, vous voudrez regarder quelque chose comme Factory Support à Castle Windsor. (Les autres conteneurs IoC ont des concepts similaires.)