Je vais essayer de donner une réponse contre une telle utilisation, après avoir vu et travaillé sur cela dans l'un de mes projets également.
Lisibilité du code
Tout d'abord, considérez que la lisibilité du code est importante et cette pratique va à l'encontre de cela. Quelqu'un lit un morceau de code et disons simplement qu'il a une fonction doSomething(Employee e). Ce n'est plus lisible, car en raison de 10 Employeeclasses différentes existant dans différents packages, vous devrez d'abord recourir à la déclaration d'importation pour savoir ce que votre entrée est vraiment.
Cependant, c'est une vue de haut niveau et nous avons souvent des conflits de noms apparemment aléatoires, dont personne ne se soucie ni ne trouve, car la signification peut être dérivée du code restant et du paquet dans lequel vous vous trouvez. On pourrait même argumenter que, localement, il n'y a pas de problème, car bien sûr si vous voyez Employeedans un hrpackage vous devez savoir que nous parlons d'une vision RH de l'employé.
Les choses se désagrègent dès que vous quittez ces colis. Une fois que vous travaillez dans un module / package / etc différent et que vous devez travailler avec un employé, vous sacrifiez déjà la lisibilité si vous ne qualifiez pas complètement son type. De plus, avoir 10 Employeeclasses différentes signifie que l'auto-complétion de votre IDE ne fonctionnera plus et vous devez choisir manuellement le type d'employé.
Duplication de code
En raison de la nature même de chacune de ces classes étant liées les unes aux autres, votre code est susceptible de se détériorer en raison de nombreuses duplications. Dans la plupart des cas, vous aurez quelque chose comme le nom d'un employé ou un numéro d'identification, que chacune des classes doit implémenter. Même si chaque classe ajoute son propre type de vue, si elles ne partagent pas les données sous-jacentes des employés, vous vous retrouverez avec d'énormes masses de code inutile, mais coûteux.
Complexité du code
Qu'est-ce qui peut être si complexe que vous pourriez demander? Après tout, chacune des classes peut rester aussi simple qu'elle le souhaite. Ce qui devient vraiment un problème, c'est la façon dont vous propagez les changements. Dans un logiciel raisonnablement riche en fonctionnalités, vous pourrez peut-être modifier les données des employés - et vous souhaitez les refléter partout. Dis qu'une femme vient de se marier et que tu dois la renommer de XàYà cause de ça. Assez difficile pour faire ça partout, mais encore plus difficile quand vous avez toutes ces classes distinctes. Selon vos autres choix de conception, cela peut facilement signifier que chacune des classes doit implémenter son propre type d'écouteur ou tel pour être averti des modifications - ce qui se traduit essentiellement par un facteur appliqué au nombre de classes que vous devez traiter . Et plus de duplication de code bien sûr, et moins de lisibilité du code, .. Des facteurs comme celui-ci peuvent être ignorés dans l'analyse de complexité, mais ils sont certainement ennuyeux lorsqu'ils sont appliqués à la taille de votre base de code.
Communication de code
Outre les problèmes de complexité du code ci-dessus, qui sont également liés aux choix de conception, vous réduisez également la clarté de votre conception de niveau supérieur et perdez la capacité de communiquer correctement avec les experts du domaine. Lorsque vous discutez d'architecture, de conceptions ou d'exigences, vous n'êtes plus libre de faire des déclarations simples comme given an employee, you can do .... Un développeur ne saura plus ce que employeesignifie vraiment à ce stade. Bien qu'un expert en domaine le sache bien sûr. Nous faisons tous. sorte de. Mais en termes de logiciel, il n'est plus si facile de communiquer.
Comment se débarrasser du problème
Après avoir pris conscience de cela et si votre équipe convient qu'il s'agit d'un problème suffisamment important pour être résolu, vous devrez trouver un moyen de le résoudre. En règle générale, vous ne pouvez pas demander à votre manager de donner une semaine de congé à toute l'équipe afin qu'ils puissent sortir les poubelles. Donc, en substance, vous devrez trouver un moyen d'éliminer partiellement ces classes, une à la fois. La partie la plus importante à ce sujet est de décider - avec toute l'équipe - ce qu'est Employeevraiment un . N'intégrez pas tous les attributs individuels en un seul employé divin. Pensez davantage à un employé de base et, surtout, décidez où cette Employeeclasse résidera.
Si vous effectuez des révisions de code, il est particulièrement facile de vous assurer que le problème ne s'aggrave pas au moins, c'est-à-dire d'arrêter tout le monde dans sa piste lorsqu'il souhaite en ajouter un autre Employee. Veillez également à ce que les nouveaux sous-systèmes adhèrent à l'accord Employeeet ne soient pas autorisés à accéder aux anciennes versions.
Selon votre langage de programmation, vous pouvez également vouloir marquer les classes qui seront finalement éliminées avec quelque chose comme @Deprecatedpour aider votre équipe à réaliser immédiatement qu'elles travaillent avec quelque chose qui devra être changé.
En ce qui concerne l'élimination des classes d'employés obsolètes, vous pouvez décider pour chaque cas individuel de la meilleure façon de les éliminer, ou simplement convenir d'un modèle commun. Vous pouvez apposer le nom de la classe et l'enrouler autour du véritable employé, vous pouvez utiliser des modèles (décorateur ou adaptateur me viennent à l'esprit), ou, ou ou.
Pour faire court: cette "pratique" est techniquement solide, mais elle est étouffée par des coûts cachés qui ne se produiront que plus loin. Bien que vous ne puissiez pas vous débarrasser immédiatement du problème, vous pouvez commencer immédiatement à contenir ses effets nocifs.