Est-il courant d'utiliser des classes partielles pour atteindre la «modularité»?

J'ai récemment rencontré une situation dans notre base de code où une autre équipe a créé une «classe divine» contenant environ 800 méthodes, réparties sur 135 fichiers en tant que classe partielle.

J'ai demandé à l'autre équipe à ce sujet. Bien que ma réaction instinctive ait été de le faire disparaître de l'orbite, ils insistent sur le fait que c'est une bonne conception, une pratique courante, et qu'il favorise la `` modularité '' et la `` facilité de mise en œuvre '' parce que les nouveaux développeurs peuvent intégrer des fonctionnalités sans presque aucune connaissance du reste. du système.

Est-ce en fait une pratique courante ou en quelque sorte une bonne idée? Je suis enclin à prendre des mesures immédiates pour faire tomber cette bête (ou du moins l'empêcher de grandir), mais je suis prêt à croire que je me trompe.

Ce n'est en aucun cas une bonne idée.

Des classes partielles existent pour aider le concepteur de formulaires. Les utiliser pour toute autre raison (et sans doute pour leur objectif, mais c'est une autre affaire) est une mauvaise idée, car elle conduit à des classes gonflées qui sont difficiles à lire et à comprendre.

Regardez-le de cette façon: si une classe divine avec 800 méthodes dans un fichier, où vous savez où tout est, est une mauvaise chose - et je pense que tout le monde serait d'accord - alors comment une classe divine avec 800 méthodes répartis sur 135 fichiers, où vous ne savez pas où tout est peut-être une bonne chose?

La question était donc:

Est-ce en fait une pratique courante ou en quelque sorte une bonne idée?

Parmi les réponses actuellement disponibles figure un non retentissant . Donc, il y a peu d'autres choses que je pourrais carillon comme à ce sujet; même le code procédural peut être modulaire et inclure tout, mais l'évier de cuisine n'est pas la façon dont vous atteignez la modularité. Ce qu'une classe géante divisée en partiels fait, tout cela se résume en un gros gâchis.

Mais cette question est hareng rouge pour la vraie partie critique de ce qui a été manqué; que le PO a également à dire sur la situation:

(...) Alors que ma réaction intestinale a été de le neutraliser de l'orbite, ils insistent ...

(...) Je suis enclin à prendre des mesures immédiates pour faire tomber cette bête (ou du moins l'empêcher de grandir davantage) mais je suis prêt à croire que je me trompe.

CALMEZ-VOUS!

Voici quelque chose qui ferait tomber mon monocle au sens figuré dans ma tasse de thé figurative.

J'ai été dans des situations similaires et permettez-moi de vous dire: NE PAS tombez dans le besoin de le faire. Bien sûr, vous pouvez laisser tomber le Nuke Hammer of Justice dans l'équipe, mais avant de le faire, veuillez vous humourer avec l'énigme suivante:

Que se passera-t-il si vous dites à l'équipe que son code est nul et qu'il s'enfonce ?

(... ou quelque chose comme ça, mais moins offensant, cela n'a pas vraiment d'importance car ils seront offensés indépendamment de ce que vous faites si vous décidez de leur donner toute leur force)

Quelle est la situation actuelle avec la base de code? Est-ce que ça marche? Ensuite, vous aurez de gros problèmes à expliquer à leurs clients que leur code est essentiellement nul . Peu importe leurs raisons: tant qu'il fonctionne, la plupart des clients ne se soucient pas de l'organisation du code.

Mettez-vous également à leur place, que feraient-ils? Permettez-moi de vous amuser avec le résultat très possible suivant:

Membre de l'équipe n ° 1: "Il y a donc ce type qui nous dit que nous avons mal agi ces dernières années."

Membre de l'équipe # 2 et # 3: "Quel connard."

Membre influent de l'équipe n ° 4: "Ne vous inquiétez pas, je vais simplement aller voir la direction et le signaler comme un harcèlement."

Voyez ce que le membre influent de l'équipe # 4 a fait là-bas? Il est allé à la direction et a réduit votre karma dans l'entreprise. Il pourrait être américano-italien, disant à tout le monde de ne pas s'en inquiéter, mais je serais alors raciste à ce sujet.

Peindre l'équipe fautive dans un coin en lui permettant d'admettre qu'elle a mal agi pendant si longtemps est également une mauvaise idée et conduit à la même chose. Vous perdrez du respect et du karma politique de bureau.

Même si vous avez réussi à amener un tas de gens à signer, afin de "donner une leçon à l'équipe", rappelez-vous que vous faites cela à des gens assez intelligents qui, apparemment, accomplissent certaines tâches. Une fois que le code sera réécrit / refactorisé / traité / quoi que ce soit et que des problèmes surviennent, vous serez tenu responsable car vous étiez le pompier .

Être adversaire dans des situations comme celle-ci est principalement un jeu perdant / perdant car il risque de devenir un cercle vicieux de jeux de blâme. Il s'agit d'un résultat sous-optimal pour cette situation. Même si vous gagnez, vous êtes soudainement remis le désordre que quelqu'un d'autre a fait.

Il existe d'autres moyens (très matures)

J'étais dans une situation similaire une fois, mais j'ai ensuite pris une flèche au genou. Donc, après un moment avec cette flèche soudaine de changement de carrière dans mon esprit, j'ai eu un livre Driving Technical Change de Terrence Ryan . Il énumère plusieurs modèles de sceptiques, le genre de personnes n'agissant pas sur de bonnes idées. Ils sont tous très probablement applicables dans le cas du PO:

• Les non-informés - Ils ne savaient vraiment pas qu'il y avait d'autres moyens ou tout simplement ne comprenaient pas. Les développeurs juniors entrent généralement dans cette catégorie, mais pas nécessairement. (Pour être honnête: j'ai rencontré des développeurs juniors qui seraient plus brillants que cela.)
• Le troupeau - Ils connaissaient de meilleures techniques que l'utilisation de classes partielles mais ne savaient pas qu'ils étaient autorisés.
• The Cynic - Ils aiment juste affirmer qu'avoir des cours partiels est mieux que votre idée juste pour discuter. C'est facile de le faire dans une foule au lieu de se tenir devant une foule.
• The Burned - Pour une raison étrange, ils n'aiment pas créer de nouvelles classes, très probablement ils le perçoivent comme trop difficile.
• The Time Crunched - Ils sont tellement occupés qu'ils ne peuvent pas prendre la peine de corriger leur code.
• Le patron - Ils pensent: "Eh bien, ça marche; alors pourquoi s'embêter?"
• L'Irrationnel - Ok, ils sont juste complètement fous.

Le livre continue avec une liste de stratégies et ainsi de suite, mais dans le cas du PO, c'est une question de persuasion. Aller fort avec des faits sur l'anti-modèle ne suffit pas.

S'il est dans votre intérêt d'améliorer la qualité du code, donnez au moins à l'équipe fautive des chances de réitérer et de rectifier son propre gâchis . Personnellement, j'essayerais de les influencer en les écoutant et en posant des questions directrices, en les laissant raconter leur histoire:

• Que fait exactement leur classe de dieu?
• Ont-ils rencontré des problèmes? Ont-ils des bugs? Suggérez des corrections sensées sans leur dire de le faire.
• Si vous êtes un utilisateur de cette classe divine en tant qu'API: existe-t-il des moyens plus simples d'utiliser le code que d'utiliser le tout? Suggérez des exemples plus simples, voyez comment ils réagissent.
• Pouvez-vous changer certaines fonctionnalités avec une autre, sans avoir à écrire la fonction?
• Ont-ils besoin d'une formation? Pouvez-vous convaincre la direction de lui en donner ou de prendre des déjeuners sur les modèles et les pratiques?

... etc. Donnez-leur de petites suggestions pour qu'ils puissent aller de l'avant. Cela prend du temps et aura besoin d'un peu d' huile de coude de qualité politique, mais la patience et le travail acharné sont une vertu, n'est-ce pas?

La page Classes et méthodes partielles MSDN propose deux situations pour utiliser des classes partielles:
1. Pour diviser une classe géante en plusieurs fichiers distincts.
2. Pour avoir un endroit pour mettre le code source généré automatiquement.

2 est largement utilisé par Visual studio (par exemple, pour les fichiers aspx et pour les winforms). Il s'agit d'une utilisation raisonnable des classes partielles.

1 est ce que fait votre équipe. Je dirais que l'utilisation de classes partielles est un moyen parfaitement raisonnable d'atteindre la modularité lorsque vous avez des classes géantes, mais avoir des classes géantes est en soi déraisonnable. En d'autres termes, avoir une classe géante est une mauvaise idée, mais si vous allez avoir une classe géante, les classes partielles sont une bonne idée.

Bien que si vous pouvez diviser intelligemment une classe en fichiers séparés pour différents utilisateurs, ne pouvez-vous pas simplement la diviser en classes distinctes?

Donc en fin de compte, ils font un développement procédural normal sans aucun morceau de POO. Ils ont un espace de noms global avec toutes les méthodes, les variables et ainsi de suite.

Soit les persuader qu'ils se trompent, soit foutre le camp.

Une classe utilitaire contient des méthodes qui ne peuvent pas être sensiblement combinées avec d'autres méthodes pour créer une classe. Si vous avez plus de 800 méthodes, réparties en 135 fichiers, il semble probable que quelqu'un a réussi à trouver des méthodes courantes ...

Ce n'est pas parce que vous avez une classe utilitaire que vous ne pouvez pas avoir une autre classe utilitaire.

Même si vous disposez de 800 méthodes pour la plupart indépendantes, la solution n'est pas une grande classe et beaucoup de fichiers. La solution est un espace de noms, quelques sous-espaces de noms et beaucoup de petites classes. C'est un peu plus de travail (vous devez trouver un nom pour la classe ainsi que la méthode). Mais cela vous facilitera la vie quand viendra le temps de nettoyer ce gâchis, et en attendant, cela rendra Intellisense plus facile à utiliser (c'est-à-dire plus facile à découvrir où une méthode doit l'utiliser).

Et non, ce n'est pas courant (plus le nombre de fichiers que le nombre de fonctions gratuites).

Je n'aime pas ça du tout. Cependant, les classes partielles avaient peut-être un sens pour les développeurs pendant le développement car elles permettaient le développement simultané de ce grand nombre de méthodes, surtout s'il n'y avait pas beaucoup de dépendance entre elles.

Une autre possibilité est que ces classes partielles ont été construites pour modifier une classe principale générée automatiquement. Si tel est le cas, il ne faut pas les toucher, sinon le code personnalisé serait effacé lors de la régénération.

Je ne suis pas sûr que quiconque puisse maintenir cela facilement sans étude. Maintenant, si vous le tuez, le nombre de méthodes ne diminuera pas. Le nombre de méthodes et de complexité, pour moi, est le vrai problème. Si les méthodes appartiennent vraiment à la classe, alors avoir 1 gros fichier ne va pas vous faciliter la vie, spécialement en maintenance, en fait, il peut être plus sujet aux erreurs d'exposer tout ce code pour des erreurs idiotes comme la recherche de caractères génériques et remplacer.

Soyez donc prudent et justifiez la décision de tuer. Réfléchissez également aux tests qui seront nécessaires.

C'est parfaitement bien du point de vue de la conception pratique, en supposant que les 135 fichiers regroupent en fait des méthodes similaires à ce que feraient les classes traditionnelles. C'est seulement une moyenne de 6 méthodes par fichier. Ce n'est certainement pas la façon la plus populaire ou traditionnelle de concevoir un projet. Essayer de le changer ne fera que créer un tas de problèmes et de mauvaise volonté sans réel avantage. Rendre le projet conforme aux normes OO créera autant de problèmes qu'il en résoudra. C'est une tout autre affaire si les fichiers multiples ne fournissent pas réellement de séparations significatives.

Au-delà des réponses déjà signalées, les classes partielles peuvent être utiles dans une conception en couches où vous souhaitez organiser des fonctionnalités qui coupent votre hiérarchie de classes en plusieurs fichiers spécifiques aux couches. Cela permet d'utiliser l'explorateur de solutions pour naviguer dans les fonctionnalités par couche (par organisation de fichiers) et la vue de classe pour naviguer dans les fonctionnalités par classe. Je préférerais utiliser un langage qui prend en charge les mixins et / ou les traits, mais les classes partielles sont une alternative raisonnable si elles sont utilisées avec parcimonie, et ne devraient pas remplacer une bonne conception de la hiérarchie des classes.