Il est temps d’arrêter de structurer votre code en tant que framework de débutant que les tutoriels vous ont autrefois enseigné.
À présent, vous devriez capturer les connaissances du domaine dans un code de travail et protéger ces connaissances dans votre contexte contre la contamination et les excès d’autres contextes. Qu’ont en commun ProductRepository et BasketRepository ? Rien. Les deux abordent des problèmes différents, alors pourquoi les regrouper ?
Product, ProductService et ProductRepository sont fortement couplés ; pourquoi ne les regrouperiez-vous pas ? Cohésion – le code qui change ensemble, reste ensemble, soigneusement encapsulé. Plus votre niveau d’accès est restreint, moins il y a de chances de créer des dépendances inutiles qui finiront dans une grosse boule de boue.
Il faut résister à la tentation de tout rendre public ! C’est pourquoi les bases de code se transforment en une masse d’objets interconnectés. Il est essentiel d’organiser correctement vos colis. Les packages doivent contenir toutes les classes d’un domaine/contexte spécifique et ne donner accès à d’autres packages que via une interface unique. Ensuite, au lieu d’écrire des tests unitaires pour chaque méthode publique de chaque classe, écrivez des tests unitaires en vous concentrant sur l’interface publique du composant, couvrant chaque comportement de l’unité. Consultez mon article sur les tests efficaces
Les composants ayant un objectif unique et bien défini sont faciles à comprendre et beaucoup plus lisibles. Le nom de ces composants annonce clairement leur objectif, et une telle unité fait exactement cela.
Le résumé de base de l’histoire est que les choses deviennent beaucoup plus faciles à comprendre et à maintenir si vos idées architecturales sont explicitement mappées dans le code. Votre code doit refléter les diagrammes d’architecture que vous dessinez.
Cohésion vs Couplage
Le code qui change ensemble reste ensemble. Le code qui sert un objectif commun reste ensemble. La cohésion est un concept assez simple, et j’espère que vous l’avez déjà compris.
Le couplage est la prochaine chose importante que vous devez apprendre correctement. Il s’agit de savoir à quel point un composant dépend ou interagit avec d’autres composants.
Idéalement, nous devrions viser une forte cohésion et un faible couplage. Appliquer le principe de responsabilité unique (PRS) pour une cohésion élevée. Utilisez des interfaces bien définies et une inversion de contrôle pour un faible couplage.
Le faible couplage signifie moins d’interconnexions entre les composants. Cela signifie qu’un composant peut être modifié ou même remplacé sans affecter les autres composants.
Lorsque le logiciel est décomposé en composants plus petits, ces composants interagiront inévitablement les uns avec les autres et il faudra des limites clairement définies pour ne pas divulguer le domaine. Le résultat est un système qui consiste en des contextes coopérants mais indépendants et délimités.
Le résumé de base de l’histoire est que les choses deviennent beaucoup plus faciles à comprendre et à maintenir si nous pouvons efficacement tracer et appliquer des limites pendant le développement.
Démo
J’ai créé un projet où j’ai conçu et mis en œuvre une application monolithique qui a été construite en utilisant les principes de modularité. Vérifiez-le! J’ai également enregistré une vidéo parcourant le projet en soulignant ce que nous avons discuté dans cet article.