La taille du constructeur est-elle importante si vous utilisez Inversion of Control?

Question

Donc, j'ai peut-être 10 objets dont chacun a 1 à 3 dépendances (ce qui me semble correct en ce qui concerne le couplage faible), mais également certains paramètres qui peuvent être utilisés pour définir le comportement (délai d'attente, taille de la fenêtre, etc).

Avant d’utiliser un conteneur Inversion of Control, j’aurais créé une fabrique et peut-être même un simple objet ObjectSettings pour chacun des objets nécessitant plus d’un paramètre pour conserver la taille du constructeur aux valeurs recommandées. que 4 " taille du paramètre. J'utilise maintenant une inversion de conteneur de contrôle et je ne vois tout simplement pas trop son sens. Bien sûr, je pourrais obtenir un constructeur avec 7 paramètres, mais qui s'en soucie? De toute façon, tout est rempli par l'IoC.

Est-ce que je manque quelque chose ici ou est-ce fondamentalement correct?

Answer 1

La relation entre la complexité de la classe et la taille du constructeur IoC ne m’était pas apparue avant de lire cette question, mais mon analyse ci-dessous suggère qu’avoir de nombreux arguments dans le constructeur IoC est un odeur de code à prendre en compte lors de l'utilisation d'IoC. Avoir pour objectif de s'en tenir à une courte liste d'arguments de constructeur vous aidera à garder les classes simples. En vous conformant au principe de responsabilité unique , vous serez guidé vers cet objectif.

Je travaille sur un système qui compte actuellement 122 classes instanciées à l'aide du framework Spring.NET. Toutes les relations entre ces classes sont définies dans leurs constructeurs. Certes, le système a sa juste part de code moins que parfait où j'ai enfreint quelques règles. (Mais, hé, nos échecs sont des occasions d'apprendre!)

Les constructeurs de ces classes ont un nombre variable d'arguments, ce que je montre dans le tableau ci-dessous.

Number of constructor arguments    Number of classes
           0                             57
           1                             19
           2                             25
           3                              9
           4                              3
           5                              1
           6                              3
           7                              2
           8                              2

Les classes sans argument sont soit des classes de stratégie concrètes, soit des classes qui répondent à des événements en envoyant des données à des systèmes externes.

Ceux qui ont 5 ou 6 arguments sont tous un peu inélégants et pourraient utiliser un refactoring pour les simplifier.

Les quatre classes avec 7 ou 8 arguments sont d'excellents exemples d'objets Dieu . Ils doivent être dissociés et chacun figure déjà sur ma liste de points chauds au sein du système.

Les classes restantes (1 à 4 arguments) sont (pour la plupart) simplement conçues, faciles à comprendre et conformes au principe de responsabilité unique .

Answer 2

La nécessité de nombreuses dépendances (peut-être plus de 8) pourrait indiquer un défaut de conception, mais en général, je pense qu’il n’ya pas de problème tant que la conception est cohérente.

Pensez également à utiliser un localisateur de services ou une passerelle statique pour des problèmes d'infrastructure tels que la journalisation et l'autorisation, plutôt que d'encombrer les arguments du constructeur.

EDIT: 8 est probablement trop, mais j’ai pensé qu’il y aurait un cas étrange. Après avoir regardé l'article de Lee, je suis d'accord, 1-4 est généralement bon.

Answer 3

G'day George,

Tout d’abord, quelles sont les dépendances entre les objets?

Beaucoup de " isa " des relations? Beaucoup de & has; & hasa " relations?

Beaucoup de fan-in? Ou fan-out?

La réponse de George: "essaie principalement de suivre la composition plutôt que de donner des conseils sur l'héritage ... Pourquoi est-ce important alors?"

Comme il s’agit surtout de "hasa" ça devrait aller.

Veillez à ce que votre construction (et votre destruction) des composants soit correctement effectuée afin d'éviter les fuites de mémoire.

Et si c'est en C ++, assurez-vous d'utiliser des destructeurs virtuels?

Answer 4

C’est une question difficile, et pourquoi je préconise une approche hybride dans laquelle les propriétés appropriées sont modifiables et où seules les propriétés immuables et les dépendances requises sans valeur par défaut utile font partie du constructeur. Certaines classes sont construites avec l'essentiel, puis ajustées si nécessaire via des setters.

Answer 5

Tout dépend du type de conteneur que vous avez utilisé pour effectuer l'IOC et des approches adoptées par le conteneur, qu'il utilise des annotations ou un fichier de configuration pour saturer l'objet à instancier. De plus, si vos paramètres de constructeur ne sont que des types de données primitifs, ce n’est pas vraiment grave; Toutefois, si vous avez des types non primitifs, alors à mon avis, vous pouvez utiliser l'ID basé sur la propriété plutôt que l'ID basé sur le constructeur.