Les classes de manager peuvent-elles être un signe de mauvaise architecture?

Dernièrement, j'ai commencé à penser qu'avoir beaucoup de cours de gestion dans votre conception était une mauvaise chose. L'idée n'a pas encore mûri pour que je puisse présenter un argument convaincant, mais voici quelques points généraux:

• J'ai trouvé qu'il était beaucoup plus difficile pour moi de comprendre les systèmes qui reposent beaucoup sur les "gestionnaires". En effet, outre les composants réels du programme, vous devez également comprendre comment et pourquoi le gestionnaire est utilisé.

• Les gestionnaires semblent souvent être utilisés pour résoudre un problème de conception, par exemple lorsque le programmeur ne pouvait pas trouver le moyen de rendre le programme Just Work ^TM et devait compter sur les classes de gestionnaires pour que tout fonctionne correctement.

Bien sûr, les gestionnaires peuvent être bons. Un exemple évident est une EventManagerde mes constructions préférées. : P Mon point est que les gestionnaires semblent être surexploités la plupart du temps et sans autre bonne raison que de masquer un problème d'architecture de programme.

Les classes de manager sont-elles vraiment un signe de mauvaise architecture?

Les classes de gestionnaires peuvent être le signe d’une mauvaise architecture, pour plusieurs raisons:

• Identificateurs sans signification

  Le nom FooManagerne dit rien sur ce que la classe fait fait , sauf qu'il implique en quelque sorte des Foocas. Donner à la classe un nom plus significatif élucide son véritable objectif, ce qui conduira probablement à la refactorisation.

• Responsabilités fractionnelles

  Selon le principe de responsabilité unique, chaque unité de code devrait avoir exactement un objectif. Avec un responsable, vous pouvez diviser artificiellement cette responsabilité.

  Considérez un système ResourceManagerqui coordonne la durée de vie et l'accès aux Resourceinstances. Une application a un seul à ResourceManagertravers lequel elle acquiert des Resourceinstances. Dans ce cas, il n'y a pas de vraie raison pour que la fonction d'une ResourceManagerinstance ne puisse pas être servie par des méthodes statiques dans la Resourceclasse.

• Abstraction non structurée

  Souvent, un responsable est introduit pour résoudre les problèmes sous-jacents liés aux objets qu’il gère. C’est la raison pour laquelle les gestionnaires se prêtent mal à l’utilisation abusive de systèmes mal conçus. L’abstraction est un bon moyen de simplifier un système complexe, mais le nom de «gestionnaire» n’indique pas la structure de l’abstraction qu’il représente. Est-ce vraiment une usine, ou un proxy, ou autre chose?

Bien entendu, les gestionnaires peuvent être utilisés pour plus que le mal, pour les mêmes raisons. Un EventManager—qui est vraiment un — met en Dispatcherfile d'attente les événements et les envoie aux cibles intéressées. Dans ce cas, il est judicieux de séparer la responsabilité de la réception et de l’envoi d’événements, puisqu’un individu Eventn’est qu’un message sans notion de provenance ou de destination.

Nous écrivons un Dispatcherdes Eventexemples essentiellement pour la même raison que nous écrivons un GarbageCollectorou un Factory:

Un responsable sait ce que sa charge utile n’aurait pas besoin de savoir.

Je pense que c'est la meilleure justification qui existe pour créer une classe semblable à celle d'un gestionnaire. Lorsque vous avez un objet «payload» qui se comporte comme une valeur, il devrait être aussi stupide que possible pour que le système global reste flexible. Pour donner un sens à des instances individuelles, vous créez un gestionnaire qui coordonne ces instances de manière significative. Dans toute autre situation, les gestionnaires sont inutiles.

Les gestionnaires peuvent être le signe d’une mauvaise architecture, mais le plus souvent ils ne sont qu’un signe d’une incapacité de la part du concepteur à proposer de meilleurs noms pour ses objets, ou tout simplement un reflet du fait que la langue anglaise (et tout langage humain d'ailleurs) convient à la communication de concepts pratiques de tous les jours, et non de concepts extrêmement abstraits et hautement techniques.

Un exemple simple pour illustrer mon propos: avant que le motif d'usine ne soit nommé, les gens l'utilisaient, mais ils ne savaient pas comment l'appeler. Donc, quelqu'un qui a dû écrire une usine pour sa Fooclasse peut l'avoir appelée FooAllocationManager. Ce n'est pas un mauvais design, c'est juste un manque d'imagination.

Et puis, quelqu'un doit mettre en place une classe qui gère de nombreuses usines et les distribue à divers objets qui les demandent. et il appelle sa classe FactoryManagerparce que le mot Industryne lui est jamais venu à l'esprit, ou il pensait que ce ne serait pas cool, car il n'avait jamais entendu parler de cela dans la programmation. Encore une fois, un cas de manque d'imagination.

Avoir beaucoup de classes "manager" est souvent le symptôme d'un modèle de domaine anémique , dans lequel la logique de domaine est extraite du modèle de domaine et placée dans des classes de manager, qui correspondent plus ou moins aux scripts de transaction . Le danger ici est que vous reveniez essentiellement à la programmation procédurale - cela en soi peut ne pas être une bonne chose en fonction de votre projet - mais le fait qu’il n’ait pas été pris en compte ou envisagé est le véritable problème à l’imo.

Suivant le principe de «l'expert en information» , une opération logique devrait résider aussi près que possible des données nécessaires. Cela impliquerait de replacer la logique de domaine dans le modèle de domaine, de sorte que ce soient ces opérations logiques qui ont un effet observable sur l'état du modèle de domaine, plutôt que de «changer» les gestionnaires de l'état du modèle de domaine de l'extérieur.

Réponse courte: ça dépend .

Il existe plusieurs formes distinctes de "classes de gestionnaires", certaines bonnes et d'autres mauvaises, et pour la plupart d'entre elles, le contexte dépend beaucoup de la pertinence d'introduire une classe de gestionnaires. Un bon point de départ pour les obtenir est de suivre le principe de responsabilité unique : si vous savez exactement de quoi (et non) chacun des membres de votre classe de direction est responsable, vous aurez beaucoup moins de problèmes à les comprendre.

Ou pour répondre directement à votre question: ce n’est pas le nombre de classes de gestionnaires indiquant une mauvaise architecture, mais un trop grand nombre d’entre elles avec des responsabilités peu claires ou un nombre trop élevé de problèmes.

Bien qu’il soit facile de dire qu’ils sont intrinsèquement révélateurs d’une mauvaise conception, ils peuvent également apporter beaucoup de qualité et réduire la complexité du code et d’autres codes complexes tout au long du projet en englobant une tâche et une responsabilité universelles.

La prévalence des gestionnaires peut être due à un manque de jugement sur la conception, mais également à la résolution des problèmes de conception ou à des problèmes d'incompatibilité avec d'autres composants d'une conception ou de composants d'interface utilisateur tiers, ou de services Web tiers dotés d'une interface étrange. à titre d'exemple.

Ces exemples montrent où ils sont terriblement utiles dans certaines situations pour réduire la complexité globale et promouvoir un couplage lâche entre divers composants et couches en encapsulant le "code laid" en un seul endroit. Cependant, il est évident que les gens sont tentés de nommer des gérants uniques, je vous le déconseille, et bien sûr, comme d'autres l'ont suggéré, le principe de responsabilité unique devrait toujours être suivi.

Les classes de manager peuvent-elles être un signe de mauvaise architecture?

Vous avez répondu à votre question: ils ne doivent pas nécessairement être le signe d'une mauvaise conception.

À l'exception de l'exemple de votre question avec EventManager, il existe un autre exemple: dans le modèle de conception MVC , le présentateur peut être considéré comme un gestionnaire pour les classes de modèle / vue.

Cependant, si vous abusez d'un concept, il est le signe d'un mauvais design et éventuellement d'une architecture.

Quand la classe a "Manager" dans le nom, méfiez-vous du problème de la classe des dieux (un avec trop de responsabilités). S'il est difficile de décrire le rôle d'une classe avec son nom, il s'agit d'un panneau d'avertissement de conception.

Mauvaises classes de gestionnaires mises à part, le pire nom que j'ai jamais vu était "DataContainerAdapter"

"Données" devrait être une autre de ces chaînes interdites dans les noms. Ce sont toutes des données, "données" ne vous en dit pas beaucoup dans la plupart des domaines.

Les classes de gestionnaires - comme presque toutes les classes se terminant par "-er" - sont diaboliques et n'ont rien à voir avec la POO. Donc pour moi c'est un signe de mauvaise architecture.

Pourquoi? Le nom "-er" implique qu'un concepteur de code a pris une mesure et l'a convertie en classe. En conséquence, nous avons une entité artificielle qui ne reflète aucun concept tangible, mais une action. Cela semble très procédural.

En outre, ces classes utilisent généralement certaines données et les exploitent. C'est une philosophie de données passives et de procédures actives qui a trouvé sa place dans la programmation procédurale. Si vous vous en rendez compte, il n’ya rien de mal dans les classes de gestion, mais ce n’est pas la POO alors.

La pensée objet implique que les objets se fassent des choses pour eux-mêmes. Découvrez votre domaine , construisez des réseaux sémantiques , faites de vos objets des organismes vivants, des êtres intelligents et responsables.

De tels objets n'ont pas besoin d'être contrôlés. Ils savent quoi faire et comment faire. Les classes de gestionnaires enfreignent donc deux fois les principes de la POO. En plus d'être une classe "-er", il contrôle d'autres objets. Mais cela dépend du responsable. S'il contrôle - c'est un mauvais manager. S'il coordonne, c'est un bon manager. C'est pourquoi une lettre "C" dans MVC devrait être orthographiée par "Coordinateur".

La réponse correcte à cette question est:

1. Ça dépend.

Chaque situation que vous rencontrerez lors de l'écriture du logiciel est différente. Peut-être que vous êtes dans une équipe où tout le monde sait comment les classes de manager fonctionnent en interne? Il serait complètement fou de ne pas utiliser ce design. Ou si vous essayez de faire en sorte que la conception du manager s’adresse à d’autres personnes, dans ce cas, cela pourrait être une mauvaise idée. Mais cela dépend des détails exacts.