La cohésion indique à quel point les responsabilités d'un élément logiciel sont liées et concentrées.
Le couplage fait référence à la force avec laquelle un élément logiciel est connecté à d'autres éléments.
L'élément logiciel peut être une classe, un package, un composant, un sous-système ou un système. Et lors de la conception des systèmes, il est recommandé d'avoir des éléments logiciels qui ont une cohésion élevée et prennent en charge un couplage faible .
Une faible cohésion entraîne des classes monolithiques difficiles à maintenir, à comprendre et à réduire la réutilisation. De même, un couplage élevé entraîne des classes étroitement couplées et les changements ne sont généralement pas locaux, difficiles à modifier et réduisent la réutilisation.
Nous pouvons prendre un scénario hypothétique où nous concevons un moniteur typique capable ConnectionPool
avec les exigences suivantes. Notez que cela pourrait ressembler trop à une classe simple, ConnectionPool
mais l'intention de base est simplement de démontrer un faible couplage et une forte cohésion avec un exemple simple et je pense que cela devrait aider.
- support pour obtenir une connexion
- libérer une connexion
- obtenir des statistiques sur la connexion par rapport au nombre d'utilisation
- obtenir des statistiques sur la connexion en fonction du temps
- Stockez les informations de récupération et de libération de la connexion dans une base de données pour des rapports ultérieurs.
Avec une faible cohésion, nous pourrions concevoir une ConnectionPool
classe en regroupant avec force toutes ces fonctionnalités / responsabilités dans une seule classe comme ci-dessous. Nous pouvons voir que cette classe unique est responsable de la gestion des connexions, de l'interaction avec la base de données et du maintien des statistiques de connexion.
Avec une cohésion élevée, nous pouvons répartir ces responsabilités entre les classes et les rendre plus maintenables et réutilisables.
Pour démontrer le faible couplage, nous allons continuer avec le ConnectionPool
diagramme de haute cohésion ci-dessus. Si nous regardons le diagramme ci-dessus bien qu'il supporte une forte cohésion, le ConnectionPool
est étroitement couplé à la ConnectionStatistics
classe et PersistentStore
il interagit directement avec eux. Au lieu de cela, pour réduire le couplage, nous pourrions introduire une ConnectionListener
interface et laisser ces deux classes implémenter l'interface et les laisser s'enregistrer avec la ConnectionPool
classe. Et ConnectionPool
ils parcourent ces écouteurs et les informent des événements de connexion et de libération et permettent moins de couplage.
Note / Word ou Attention: Pour ce scénario simple, cela peut ressembler à une surpuissance mais si nous imaginons un scénario en temps réel où notre application doit interagir avec plusieurs services tiers pour effectuer une transaction: couplage direct de notre code avec les services tiers signifierait que tout changement dans le service tiers pourrait entraîner des modifications de notre code à plusieurs endroits, au lieu de cela, nous pourrions avoir Facade
qui interagit avec ces multiples services en interne et toutes les modifications des services deviennent locales au Facade
et imposent un faible couplage avec le tiers prestations de service.