Chaque application MVC mature possède un modèle devenu incontrôlable. Le tableau comporte 20 colonnes ; des préférences utilisateur y sont stockées avec les informations système ; il envoie des notifications par courrier électronique et écrit d'autres modèles dans la base de données. Le modèle englobe tellement de logique d’application que toute nouvelle fonctionnalité devra probablement passer par là. C'est la classe qui fait gémir les développeurs chaque fois qu'ils l'ouvrent.
Comment en sommes-nous arrivés là?
Les applications Web démarrent généralement avec un seul objectif, afficher un seul type de données – c'est peut-être Article pour un journal en ligne ou VêtementsArticle pour un détaillant de mode. Il est courant que les praticiens MVC prennent les concepts de leurs sessions de tableau blanc sur les produits et les traduisent directement en modèles de base de données. Nous commençons donc avec un modèle de base de données qui représente un concept central dans l'application, et à mesure que de plus en plus d'exigences commerciales émergent, le moyen le moins coûteux de les satisfaire consiste à ajouter des colonnes au modèle existant. Réalisez cela au fil du temps et vous vous retrouvez avec un Dieu Objet.
Dès le départ, le problème était de prendre les concepts simples et vagues esquissés au niveau du produit et de les intégrer dans la base de code. Les ingénieurs logiciels doivent être bien conscients que les concepts que les gens utilisent dans la vie et la réflexion quotidiennes sont terriblement imprécis et chargés d'hypothèses implicites. La mise en évidence d'hypothèses implicites est souvent la contribution clé d'un ingénieur logiciel. Il est donc étonnant que nous prenions ces concepts au niveau du produit et les intégrions dans notre code. Il s'agit simplement de demander que les cas extrêmes cachés nécessitent une logique de clarification insérée dans la classe existante.
La notion de Psychologie populaire est éclairant ici. La psychologie populaire fait référence aux théories innées et vaguement spécifiées que les gens ont sur le fonctionnement des autres humains et qu'ils utilisent pour déduire leurs motivations et prédire leur comportement. Ces théories « populaires » fonctionnent assez bien dans le contexte de la vie humaine quotidienne, mais ne sont pas scientifiquement rigoureuses et contiennent des angles morts. De la même manière, les gens utilisent des « modèles d’objets populaires » dans les entreprises de logiciels. Ce sont les concepts informels que les gens construisent pour discuter de logiciels avec d'autres humains – les mots que les chefs de produit utilisent avec les ingénieurs logiciels, les cases sont dessinées sur le tableau blanc. Ils fonctionnent assez bien lorsqu’ils discutent de concepts avec d’autres humains, qui peuvent être généreux dans leurs interprétations mais peuvent s’effondrer lorsqu’ils sont formalisés sous forme de code. Ces concepts constituent un point de départ utile pour définir les fonctionnalités du produit, mais d'un point de vue OO, ils sont trop vastes pour être utilisés en tant que classes. Ils ont tendance à accumuler de la logique puisqu’ils englobent implicitement une grande partie du domaine du problème.
Tout comme le premier obstacle que les gens doivent surmonter lorsqu'ils apprennent à coder est de prendre leurs pensées et de les formuler explicitement sous forme d'étapes dans un algorithme, les ingénieurs logiciels expérimentés doivent prendre des modèles d'objets populaires et les décomposer en composants explicites pouvant être utilisés comme classes. . Dans le domaine des produits, nous pouvons commencer par un concept large « Utilisateur », mais à mesure que nous approfondissons, nous découvrirons différents éléments de logique qui seraient mieux servis en tant que classes distinctes : une préférence de facturation, un statut actuel ou des paramètres de notification. Chacun d'entre eux nécessitera sa propre logique pour répondre aux exigences du produit, et si nous ne les séparons pas pour faire de la place à la logique, nous encourrons une surcharge.
Les gens pensent souvent que la modélisation des données consiste à coder les concepts commerciaux dans un logiciel, mais il s'agit en réalité d'utiliser des classes de modèles comme outils pour construire un système. Les bases de code sont souvent mieux servies lorsque les grands modèles sont divisés en composants dont chacun répond à un élément spécifique de la logique de domaine.
