Que signifie `` faible couplage et forte cohésion ''

J'ai du mal à comprendre l'énoncé low in coupling and high in cohesion. J'ai cherché et lu beaucoup de choses à ce sujet sur Google, mais j'ai toujours du mal à comprendre.

D'après ce que je comprends High cohesion, cela signifie que nous devrions avoir des classes spécialisées pour exécuter une fonction particulière. J'espère que c'est correct? Comme une classe de validation de carte de crédit, spécialisée dans la validation des cartes de crédit uniquement.

Et vous ne comprenez toujours pas ce que signifie un couplage faible?

Ce que je crois est ceci:

La cohésion fait référence au degré auquel les éléments d'un module / d'une classe appartiennent ensemble, il est suggéré que le code associé soit proche les uns des autres, nous devons donc nous efforcer d'obtenir une cohésion élevée et lier tous les codes associés aussi près que possible. Il doit faire avec les éléments dans le module / classe.

Le couplage fait référence au degré auquel les différents modules / classes dépendent les uns des autres, il est suggéré que tous les modules soient indépendants dans la mesure du possible, c'est pourquoi un couplage faible. Cela a à voir avec les éléments parmi les différents modules / classes.

Pour visualiser l'ensemble de l'image sera utile:

La capture d'écran a été prise de Coursera .

La cohésion en génie logiciel, comme dans la vie réelle, est à quel point les éléments constituant un tout (dans notre cas, disons une classe) peuvent être déclarés qu'ils appartiennent en fait ensemble. Ainsi, il s'agit d'une mesure du degré de corrélation entre chaque élément de fonctionnalité exprimé par le code source d'un module logiciel.

Une façon de voir la cohésion en termes d'OO est de savoir si les méthodes de la classe utilisent l'un des attributs privés.

Maintenant, la discussion est plus grande que cela, mais la cohésion élevée (ou le meilleur type de cohésion - la cohésion fonctionnelle) est lorsque des parties d'un module sont regroupées parce qu'elles contribuent toutes à une seule tâche bien définie du module.

Le couplage en termes simples, c'est combien un composant (encore une fois, imaginez une classe, mais pas nécessairement) sait sur le fonctionnement interne ou les éléments internes d'un autre, c'est-à-dire combien il a de connaissances sur l'autre composant.

Le couplage lâche est une méthode d'interconnexion des composants d'un système ou d'un réseau de sorte que ces composants dépendent les uns des autres dans la mesure du possible le moins possible.

J'ai écrit un article de blog à ce sujet. Il aborde tout cela en détail, avec des exemples, etc. Il explique également les avantages de suivre ces principes.

Dans la conception de logiciels, une cohésion élevée signifie que la classe doit très bien faire une chose et une chose. Une cohésion élevée est étroitement liée au principe de responsabilité unique .

Un couplage faible suggère que la classe devrait avoir le moins de dépendances possibles. De plus, les dépendances qui doivent exister doivent être des dépendances faibles - préférez la dépendance à l'interface plutôt que la dépendance à une classe concrète, ou préférez la composition à l'héritage.

Une cohésion élevée et un couplage faible nous donnent un code mieux conçu et plus facile à maintenir.

Réponse courte et claire

• Cohésion élevée : les éléments d'une classe / module doivent fonctionner ensemble et faire une chose particulière.
• Couplage lâche : entre les différentes classes / modules doit être une dépendance minimale.

Le couplage faible est dans le contexte de deux ou plusieurs modules. Si un changement dans un module entraîne de nombreux changements dans un autre module, on dit qu'ils sont fortement couplés. C'est là que la programmation basée sur l'interface aide. Tout changement dans le module n'aura aucun impact sur l'autre module car l'interface (le moyen d'interaction) entre eux n'a pas changé.

Haute cohésion - Mettez les choses similaires ensemble. Ainsi, une classe devrait avoir une méthode ou des comportements pour faire un travail connexe. Juste pour donner un mauvais exemple exagéré: une implémentation de l'interface List ne devrait pas avoir d'opération liée à String. La classe String doit avoir des méthodes, des champs pertinents pour String et de même, l'implémentation de List doit avoir des éléments correspondants.

J'espère que cela pourra aider.

Bref, le faible couplage tel que je l'ai compris signifie que les composants peuvent être remplacés sans affecter le bon fonctionnement d'un système. Modulisez fondamentalement votre système en composants fonctionnels qui peuvent être mis à jour individuellement sans casser le système

Avez-vous un smartphone? Y a-t-il une grande application ou beaucoup de petits? Une application répond-elle à une autre? Pouvez-vous utiliser une application lors de l'installation, de la mise à jour et / ou de la désinstallation d'une autre? Le fait que chaque application soit autonome est une cohésion élevée. Le fait que chaque application soit indépendante des autres est un faible couplage. DevOps favorise cette architecture car cela signifie que vous pouvez effectuer un déploiement continu discret sans perturber l'ensemble du système.

L'héritage ou la généralisation est un exemple de couplage élevé (c'est-à-dire d'interdépendance élevée). Ce que je voulais dire par là, c'est que dans l'héritage, la classe parente définit souvent les fonctionnalités de base utilisées par sa classe enfant et le changement des méthodes de la classe parente a un impact direct sur ses classes enfants. On peut donc dire qu'il y a un plus grand degré d'interdépendance entre les classes.

La réalisation ou l'utilisation d'interface est un exemple de forte cohésion (ie faible interdépendance). Cela signifie qu'une interface propose un contrat pour toute classe qui l'implémente, mais chaque classe a le droit d'implémenter les méthodes déclarées dans l'interface à sa manière et les changements de méthode déclarés dans une classe n'affectent aucune autre classe.

Cohésion - à quel point tout est étroitement lié les uns aux autres.
Couplage - comment tout est connecté les uns aux autres.

Prenons un exemple - Nous voulons concevoir une voiture autonome.

(1) Nous avons besoin du moteur pour fonctionner correctement.

(2) Il faut que la voiture roule seule.

Toutes les classes et fonctions de (1) démarrer le moteur et le faire fonctionner fonctionnent très bien ensemble, mais n'aident pas la voiture à diriger. Nous plaçons donc ces classes derrière un contrôleur de moteur.

Toutes les classes et fonctions de (2) fonctionnent très bien pour permettre à la voiture de diriger, d'accélérer et de freiner. Ils n'aident pas la voiture à démarrer ou à envoyer de l'essence aux pistons. Nous plaçons donc ces classes derrière son propre contrôleur de conduite.

Ces contrôleurs sont utilisés pour communiquer avec toutes les classes et fonctions disponibles. Les contrôleurs communiquent alors uniquement entre eux. Cela signifie que je ne peux pas appeler une fonction de la classe des pistons de la classe des pédales d'accélérateur pour accélérer la voiture.

La classe de pédales doit demander au contrôleur de conduite de parler au contrôleur de moteur qui lui dit alors d'aller plus vite. Cela nous permet aux programmeurs d'être en mesure de trouver des problèmes et de combiner de gros programmes sans se soucier. C'est parce que tout le code fonctionnait derrière le contrôleur.

Un couplage faible et une cohésion élevée sont un phénomène recommandé.

Le couplage signifie dans quelle mesure les différents modules sont interdépendants et comment les autres modules sont affectés par la modification de certaines / considérables fonctionnalités d'un module. Un couplage faible est mis en évidence car la dépendance doit être maintenue faible afin que des modifications très minimes / négligeables soient apportées aux autres modules.

Un exemple pourrait être utile. Imaginez un système qui génère des données et les met dans un magasin de données, soit un fichier sur disque, soit une base de données.

Une cohésion élevée peut être obtenue en séparant le code de stockage de données du code de production de données. (et en fait séparer le stockage sur disque du stockage de la base de données).

Le couplage faible peut être obtenu en s'assurant que la production de données n'a aucune connaissance inutile du magasin de données (par exemple, ne demande pas au magasin de données les noms de fichiers ou les connexions de base de données).

Voici une réponse sous un angle théorique un peu abstrait:

Simplifions le problème en regardant uniquement les graphes de dépendances (dirigés) entre les objets avec état.

Une réponse extrêmement simple peut être illustrée en considérant deux cas limites de graphes de dépendances:

Le 1er cas limite : un graphe de grappes .

Un graphe de cluster est la réalisation la plus parfaite d'un graphe de dépendance à cohésion élevée et à faible couplage (étant donné un ensemble de tailles de cluster).

La dépendance entre les clusters est maximale (entièrement connectée) et la dépendance entre les clusters est minimale (zéro).

Ceci est une illustration abstraite de la réponse dans l'un des cas limites .

Le 2ème cas limite est un graphe entièrement connecté, où tout dépend de tout.

La réalité est quelque part entre les deux, le plus proche du graphe de cluster le mieux, à mon humble compréhension.

D'un autre point de vue : lorsque l'on regarde un graphe de dépendances dirigé, il devrait idéalement être acyclique, sinon les cycles forment les plus petits groupes / composants.

Un pas vers le haut / vers le bas de la hiérarchie correspond à "une instance" de couplage lâche, cohésion serrée dans un logiciel mais il est possible de voir ce principe de couplage lâche / cohésion serrée comme un phénomène répétitif à différentes profondeurs d'un graphe orienté acyclique (ou sur l'un de ses arbres couvrant).

Une telle décomposition d'un système en une hiérarchie aide à battre la complexité exponentielle (disons que chaque cluster a 10 éléments). Puis à 6 couches, c'est déjà 1 million d'objets:

10 clusters forment 1 superamas, 10 superamas forment 1 hyperamas et ainsi de suite ... sans le concept de cohésion serrée, de couplage lâche, une telle architecture hiérarchique ne serait pas possible.

Cela pourrait donc être la véritable importance de l'histoire et pas seulement le couplage à haute cohésion et faible en deux couches seulement. L'importance réelle devient claire lorsque l'on considère les abstractions de niveau supérieur et leurs interactions.

Je pense que vous avez tant de définitions rouges mais dans le cas où vous avez encore des doutes ou si vous êtes nouveau dans la programmation et que vous souhaitez approfondir cela, je vous suggérerai de regarder cette vidéo, https://youtu.be/HpJTGW9AwX0 C'est juste une référence pour obtenir plus d'informations sur le polymorphisme ... J'espère que vous comprendrez mieux cela

Couplage bas: - Restera très simple. Si vous modifiez votre module, quel impact cela aura-t-il sur les autres modules.

Exemple: - Si votre API de service est exposée en tant que JAR, toute modification de la signature de méthode interrompra l'appel de l'API (couplage High / Tight).

Si votre module et un autre module communiquent via des messages asynchrones. Tant que vous recevez des messages, votre signature de changement de méthode sera locale à votre module (couplage faible).

Bien sûr, s'il y a un changement dans le format du message, le client appelant devra faire quelques changements.