Que signifie 'faible couplage et forte cohésion'
J'ai de la difficulté à comprendre la déclaration low in coupling and high in cohesion. J'ai googlé et lu beaucoup de choses à ce sujet, mais j'ai toujours du mal à comprendre.
D'après ce que je comprends, High cohesion 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 uniquement dans la validation de cartes de crédit.
Et vous ne comprenez toujours pas ce que signifie "couplage faible"?
Ce que je crois est ceci:
La cohésion fait référence au degré d'appartenance des éléments d'un module/classe, il est suggéré que le code associé soit proche les uns des autres. Nous devons donc rechercher une cohésion élevée et lier le plus étroitement possible tous les codes associés. Cela a à voir avec les éléments dans du module/de la classe.
Le couplage indique dans quelle mesure les différents modules/classes dépendent les uns des autres. Il est suggéré que tous les modules soient indépendants autant que possible. C'est pourquoi un couplage faible. Cela a à voir avec les éléments parmi 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, représente à quel point les éléments constituant un tout (dans notre cas, disons une classe) peuvent être dits qu'ils appartiennent réellement ensemble. Il s'agit donc d'une mesure de la relation étroite entre chaque élément de fonctionnalité exprimé par le code source d'un module logiciel.
Une façon de considérer la cohésion en termes de OO consiste à utiliser les méthodes de la classe en utilisant l'un des attributs privés.
Maintenant, la discussion est plus vaste que cela, mais Haute cohésion (ou le meilleur type de cohésion - la cohésion fonctionnelle) correspond au regroupement de parties d'un module car elles contribuer à une seule tâche bien définie du module.
Coupler en termes simples, c'est combien un composant (encore une fois, imaginons une classe, mais pas nécessairement) connaît le fonctionnement interne ou les éléments internes d'un autre , c’est-à-dire combien de connaissances il a de l’autre composant.
Le couplage lâche est une méthode d'interconnexion des composants dans un système ou un réseau afin que ces composants dépendent les uns des autres dans la mesure du possible dans la pratique.
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 logicielle , une grande cohésion signifie que la classe doit faire une chose et une chose très bien. Une cohésion élevée est étroitement liée à principe de responsabilité unique .
Un faible couplage suggère que la classe devrait avoir le moins de dépendances possibles. En outre, 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, plus facile à gérer.
Le faible couplage se situe 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 par interface aide. Toute modification au sein du module n'aura pas d'impact sur l'autre module car l'interface (le moyen d'interaction) entre eux n'a pas changé.
Haute cohésion: rassemblez des choses similaires. Donc, une classe devrait avoir une méthode ou des comportements pour faire le travail lié. Juste pour donner un mauvais exemple exagéré: une implémentation de l'interface de liste 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, la mise en oeuvre de List doit avoir les éléments correspondants.
J'espère que ça t'as aidé.
Réponse courte et claire
- Cohésion élevée: Les éléments d'une classe/module doivent fonctionnellement appartenir ensemble et faire une chose en particulier.
- Couplage lâche: Parmi les différentes classes/modules, la dépendance doit être minimale.
Si je comprends bien, cela signifie que les composants peuvent être échangés sans affecter le bon fonctionnement d'un système. Fondamentalement, modulez votre système en composants opérationnels pouvant être mis à jour individuellement sans endommager le système
Avez-vous un smartphone? Existe-t-il une grosse application ou beaucoup de petites? Est-ce qu'une application répond sur une autre? Pouvez-vous utiliser une application lors de l'installation, de la mise à jour et/ou de la désinstallation d'une autre? Que chaque application soit autonome, c'est une grande cohésion. Que chaque application soit indépendante des autres est un couplage faible. DevOps privilégie cette architecture car cela signifie que vous pouvez effectuer un déploiement discret en continu sans perturber le système dans son ensemble.
Un exemple pourrait être utile. Imaginez un système qui génère des données et les place dans un magasin de données, un fichier sur disque ou une base de données.
Une cohésion élevée peut être obtenue en séparant le code de magasin de données du code de production de données. (et en fait séparant le disque de stockage de la base de données).
Un couplage faible peut être obtenu en s’assurant que la production de données n’a pas une connaissance inutile du magasin de données (par exemple, ne demande pas au magasin de données des noms de fichiers ou des connexions à une base de données).
Voici une réponse sous un angle abstrait théorique:
Simplifions le problème en ne regardant que les graphes de dépendance (dirigés) entre les objets avec état.
Une réponse extrêmement simple peut être illustrée en considérant deux cas limites des graphes de dépendance:
Le 1er cas limite : a grappes graphiques .
Un graphe de grappe est la réalisation la plus parfaite d’un graphe de dépendance à forte cohésion et faible couplage (étant donné un ensemble de tailles de grappe).
La dépendance entre les clusters est maximale (entièrement connectée) et la dépendance entre 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 mieux, dans mon humble compréhension, le plus proche du graphe en grappe.
D'un autre point de vue : dans un graphe de dépendance dirigé, idéalement, il devrait être acyclique, sinon les cycles forment les plus petits clusters/composants.
Un échelon supérieur/inférieur de la hiérarchie correspond à "un cas" de couplage lâche, de cohésion étroite dans un logiciel, mais il est possible de voir ce principe de couplage lâche/cohésion étroite comme un phénomène répétitif à différentes profondeurs d'un graphe orienté acyclique (ou l'un de ses spanning tree).
Une telle décomposition d'un système en une hiérarchie aide à dépasser la complexité exponentielle (disons que chaque cluster a 10 éléments). Ensuite, à 6 couches, il y a déjà 1 million d'objets:
10 grappes forment 1 superamas, 10 superamas forment 1 hyperamas, etc. ... sans le concept de cohésion étroite, de couplage lâche, une telle architecture hiérarchique ne serait pas possible.
Cela pourrait donc être l’importance réelle de l’histoire et pas seulement le couplage faible à haute cohésion entre deux couches seulement. L'importance réelle devient claire lorsque l'on considère les abstractions de niveau supérieur et leurs interactions.
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à est que, dans l'héritage, la classe parent définit souvent les fonctionnalités de base utilisées par sa classe enfant et que les modifications des méthodes de la classe parent ont 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'une interface est un exemple de forte cohésion (c'est-à-dire une faible interdépendance). Cela signifie qu'une interface propose un contrat pour toute classe qui l'implémente, mais que chaque classe a le droit d'implémenter les méthodes déclarées dans interface à sa manière et que 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) Nous avons besoin de la voiture pour rouler toute seule.
Toutes les classes et fonctions de (1) démarrer et faire fonctionner le moteur fonctionnent bien ensemble, mais n’aident pas la direction à conduire. 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 rendre la voiture direction, accélération et freinage. Ils n’aident pas la voiture au démarrage et n’envoient pas d’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 ne communiquent alors qu’entre eux. Cela signifie que je ne peux pas appeler une fonction de la classe de la pédale d'accélérateur pour faire avancer la voiture plus rapidement.
La classe de pédale doit demander au contrôleur de conduite de parler au contrôleur de moteur, qui lui indique ensuite d’aller plus vite. Cela permet aux programmeurs de trouver les problèmes et de combiner des programmes volumineux sans souci. En effet, le code fonctionnait entièrement derrière le contrôleur.
Un couplage faible et une cohésion élevée est 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 lors de la modification de certaines fonctionnalités/de fonctionnalités considérables d’un module. L'accent est mis sur le faible couplage, car la dépendance doit être maintenue faible, de sorte que des modifications minimes/négligeables sont apportées aux autres modules.