L'augmentation du nombre de classes augmente-t-elle la complexité du code ? [dupliquer]

Question

Cette question a déjà des réponses ici : Comment équilibrez-vous la structuration du code (peu de grosses fonctions contre plusieurs petites) ? (3 réponses) Fermé il y a 7 ans .\"2013-07-31

Pour illustrer la question, disons que nous avons deux programmeurs de compétences comparables qui résolvent tous les deux le même problème.Le code qu'ils produisent a à peu près les mêmes lignes de code, mais un programmeur utilise 5 classes tandis qu'un autre programmeur en utilise 20.

Les deux ensembles de code obtiennent des wtfs comparables par minute lors de la révision du code, ce qui implique que le code n'est pas difficile à suivre et ne fait rien de stupide.

Le code avec 20 classes est-il plus complexe que le code qui en utilise 5 ?

Answer 1

Cohésion et Accouplement sont les deux termes pertinents, cependant, il n'y a pas de réponse fixe possible en raison de leur nature contradictoire.

Cohésion

La cohésion est une mesure de la proximité des méthodes d'une classe.Si vous avez une cohésion élevée, alors la plupart de vos méthodes sont responsables d'une chose similaire, alors que si vous avez une faible cohésion, les méthodes font des choses plus ou moins indépendantes.Ceci est légèrement lié au Principe de responsabilité unique (SRP), qui nous dit que vous devez viser une cohésion élevée.

Couplage

Contrairement à la cohésion, le couplage fait référence aux interdépendances entre modules/classes.Si vous avez un couplage élevé, cela signifie que vos modules interagissent beaucoup entre eux, tandis qu'un couplage faible signifie qu'il n'y a que peu d'interactions, c'est-à-dire de petites interfaces.Encore une fois, il est facile de voir qu'un faible couplage est préférable.

Contradiction

Le problème avec la réalisation des deux, une cohésion élevée et un faible couplage, est que changer votre code pour améliorer l'un signifie que vous réduisez l'autre.

À titre d'exemple simple, considérez que toutes vos fonctionnalités sont contenues dans une seule classe.Cela signifie que vous avez un couplage extrêmement faible, ce qui est bien !Mais bien sûr, vous avez également une cohésion extrêmement faible, car toutes les méthodes de votre classe devront faire des choses différentes.

À l'autre extrême, envisagez de diviser les choses en tellement de classes, que chacune d'elles ne contient qu'une seule petite méthode.Cela signifie que vous avez une cohésion très élevée, ce qui est encore une fois une bonne chose, mais pour faire le travail réel, ces méthodes devraient accéder à de nombreuses autres classes.Ces dépendances signifient que vous obtenez également un couplage très élevé, ce qui n'est pas bon non plus.

Troquer

Essentiellement, vous vous retrouvez avec un compromis : concentrez-vous sur la cohésion et vous perdez le couplage.Concentrez-vous sur le couplage et vous perdez la cohésion.Pour bien choisir où aller sur cette échelle de compromis, le couplage et la cohésion eux-mêmes ne sont pas des critères suffisants.Au lieu de cela, vous devriez vous tourner vers d'autres critères de qualité du code et voir où ils vous mènent sur l'échelle.

Par exemple, le SRP vous donne une bonne cohésion, et il y a des gens qui défendent cela comme la seule vérité, mais bien sûr, si vous suivez le SRP très strictement, vous vous retrouvez avec beaucoup de classes et un couplage élevé.Parfois, vous pouvez constater que tout ce couplage vous cause beaucoup de problèmes.Dans un tel cas, vous pouvez justifier qu'il vaut la peine de réduire le couplage au détriment de la cohésion en violant le SRP (ou disons simplement en réinterprétant ce qu'est cette responsabilité unique ).

En tant qu'approche des meilleures pratiques, je crois que le SRP est une valeur sûre.En général, un couplage élevé est plus problématique qu'une faible cohésion, simplement parce que nous trouvons plus facile de traiter un problème localisé à une classe (cohésion).Par conséquent, si vous suivez le SRP, cela vous mènera vers l'extrémité de couplage inférieure de l'échelle des compromis, ce qui est à tout le moins un bon point de départ.

Answer 2

J'ai généralement une classe pour chacune de mes tables, plus autant d'énumérations que nécessaire pour les champs énumérés, plus les services de données et les contrôles utilisateur et toutes sortes de choses.Les seuls WTF que je reçois proviennent des utilisateurs, bien que le taux soit mesuré en heures, pas en minutes.

Puisqu'il n'y a pas de discussion sur les spécificités du langage, je ne peux que me fier à ce que je fais en C#.J'essaie généralement de créer des modèles de conception hautement reproductibles, de sorte que quelqu'un qui regarde une classe trouvera à peu près quelque chose de similaire dans les autres.Je ne sais pas comment je pourrais "réduire le nombre" compte tenu de mes règles de conception.