Différence entre cohésion et couplage


486

Quelle est la différence entre cohésion et couplage?

Comment le couplage et la cohésion peuvent-ils conduire à une conception logicielle bonne ou mauvaise?

Quels sont les exemples qui décrivent la différence entre les deux et leur impact sur la qualité globale du code?



3
Je voudrais signaler cet article: Développement logiciel SOLID, une étape à la fois . Grz, Kris.
Kris van der Mast

4
Ceci est le dernier message sur ce sujet
janisz

Réponses:


703

La cohésion fait référence à ce que la classe (ou le module) peut faire. Une faible cohésion signifierait que la classe effectue une grande variété d'actions - elle est large, non focalisée sur ce qu'elle devrait faire. Une cohésion élevée signifie que la classe se concentre sur ce qu'elle doit faire, c'est-à-dire uniquement sur les méthodes liées à l'intention de la classe.

Exemple de faible cohésion:

-------------------
| Staff           |
-------------------
| checkEmail()    |
| sendEmail()     |
| emailValidate() |
| PrintLetter()   |
-------------------

Exemple de haute cohésion:

----------------------------
| Staff                   |
----------------------------
| -salary                 |
| -emailAddr              |
----------------------------
| setSalary(newSalary)    |
| getSalary()             |
| setEmailAddr(newEmail)  |
| getEmailAddr()          |
----------------------------

Quant au couplage , il se réfère à la façon dont les deux classes / modules sont liés ou dépendants l'un de l'autre. Pour les classes à faible couplage, changer quelque chose de majeur dans une classe ne devrait pas affecter l'autre. Un couplage élevé rendrait difficile le changement et la maintenance de votre code; étant donné que les classes sont étroitement liées, un changement pourrait nécessiter une refonte complète du système.

Une bonne conception logicielle a une cohésion élevée et un faible couplage .


12
Je ne vois pas comment la suppression de quelques méthodes et l'ajout de quelques autres augmentent la cohésion. Quelqu'un peut-il m'aider ici
Saket Jain

3
@SaketJain, ce n'est pas seulement supprimer certaines méthodes et en ajouter d'autres. c'est comment les méthodes sont liées à l'objectif de la classe (si cette explication est plus claire).
mauris

4
l'exemple de faible cohésion au sommet semble assez bon, je pense que vous vouliez accidentellement dire "forte cohession"
relipse

37
@SaketJain La classe Staff ce n'est pas l'endroit où nous vérifions, envoyons ou validons les e-mails. Ces fonctions devraient entrer dans une classe de messagerie hypothétique, c'est la raison pour laquelle il s'agit d'une faible cohésion. Dans le deuxième exemple, la classe Staff ne contient que les informations appropriées pour définir et obtenir des données relatives au personnel. Ils n'exécutent pas d'actions qui devraient être gérées par une autre classe.
Antonio Pantano

3
@JonathanC les exemples n'ont pas besoin de prouver la différence (comme dans une preuve mathématique) pour être toujours un exemple. N'hésitez pas à répondre ou à commenter les exemples qui vous semblent plus utiles. Les fonctions set& getillustrent des fonctionnalités plus spécifiques au contexte "Personnel" - la spécificité plus élevée donne à cet exemple sa plus grande cohésion.
cellepo

81

La cohésion est l'indication de la relation au sein d' un module.

Le couplage est l'indication des relations entre les modules.

entrez la description de l'image ici

Cohésion

  • La cohésion est l'indication de la relation au sein du module.
  • La cohésion montre la force fonctionnelle relative du module.
  • La cohésion est un degré (qualité) auquel un composant / module se concentre sur la seule chose.
  • Lors de la conception, vous devez viser une cohésion élevée, c'est-à-dire un composant / module cohérent se concentrant sur une seule tâche (c'est-à-dire la détermination) avec peu d'interaction avec les autres modules du système.
  • La cohésion est le type d'extension naturelle de la dissimulation de données par exemple, une classe ayant tous les membres visibles avec un package ayant une visibilité par défaut. La cohésion est le concept intra-module.

Couplage

  • Le couplage est l'indication des relations entre les modules.
  • Le couplage montre la dépendance / interdépendance relative entre les modules.
  • Le couplage est un degré auquel un composant / module est connecté aux autres modules.
  • Lors de la conception, vous devez viser un faible couplage, c'est-à-dire que la dépendance entre les modules doit être moindre.
  • Faire des champs privés, des méthodes privées et des classes non publiques offre un couplage lâche.
  • Le couplage est un concept inter-modules.

vérifier ce lien


77

Une cohésion élevée au sein des modules et un faible couplage entre les modules sont souvent considérés comme liés à la haute qualité des langages de programmation OO.

Par exemple, le code à l'intérieur de chaque classe Java doit avoir une cohésion interne élevée, mais être aussi faiblement couplé que possible au code des autres classes Java.

Le chapitre 3 de la construction logicielle orientée objet de Meyer (2e édition) est une excellente description de ces problèmes.


3
Les concepts ne sont pas vraiment limités à la programmation OO. Si quoi que ce soit, je dirais qu'un objectif des langages OO est de guider le programmeur vers les objectifs de haute cohésion / bas couplage.
Hutch

57

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 ConnectionPoolavec les exigences suivantes. Notez que cela pourrait ressembler trop à une classe simple, ConnectionPoolmais 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.

  1. support pour obtenir une connexion
  2. libérer une connexion
  3. obtenir des statistiques sur la connexion par rapport au nombre d'utilisation
  4. obtenir des statistiques sur la connexion en fonction du temps
  5. 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 ConnectionPoolclasse 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.

Pool de connexion à faible cohésion

Avec une cohésion élevée, nous pouvons répartir ces responsabilités entre les classes et les rendre plus maintenables et réutilisables.

Pool de connexion à haute cohésion

Pour démontrer le faible couplage, nous allons continuer avec le ConnectionPooldiagramme de haute cohésion ci-dessus. Si nous regardons le diagramme ci-dessus bien qu'il supporte une forte cohésion, le ConnectionPoolest étroitement couplé à la ConnectionStatisticsclasse et PersistentStoreil interagit directement avec eux. Au lieu de cela, pour réduire le couplage, nous pourrions introduire une ConnectionListenerinterface et laisser ces deux classes implémenter l'interface et les laisser s'enregistrer avec la ConnectionPoolclasse. Et ConnectionPoolils parcourent ces écouteurs et les informent des événements de connexion et de libération et permettent moins de couplage.

Connexion à faible 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 Facadequi interagit avec ces multiples services en interne et toutes les modifications des services deviennent locales au Facadeet imposent un faible couplage avec le tiers prestations de service.


3
Excellente réponse! Si possible, pourriez-vous utiliser un autre exemple? Le pool de connexions peut ne pas être clair pour tout le monde. Quoi qu'il en soit, cela m'a vraiment aidé. Donc merci!
Saket Jain

comment l'utilisation de l'interface ConnectionListener contribue-t-elle à réduire le couplage? Pouvez-vous fournir un exemple plus facile à comprendre.
abhishek gupta

1
@abhishekgupta Dans cet exemple, vous avez peut-être remarqué que nous avons utilisé un modèle d'observateur pour obtenir un couplage faible / lâche. Passer par là aiderait Comment Observer crée-t-il une conception faiblement couplée?
Madhusudana Reddy Sunnapu

33

Une cohésion et un couplage accrus conduisent à une bonne conception logicielle.

La cohésion partitionne vos fonctionnalités afin qu'elles soient concises et les plus proches des données qui les concernent, tandis que le découplage garantit que l'implémentation fonctionnelle est isolée du reste du système.

Découplage vous permet de modifier l'implémentation sans affecter d'autres parties de votre logiciel.

Cohésion garantit une implémentation plus spécifique aux fonctionnalités et en même temps plus facile à maintenir.

La méthode la plus efficace pour diminuer le couplage et augmenter la cohésion est la conception par interface .

C'est-à-dire que les principaux objets fonctionnels ne devraient se «connaître» que par l'intermédiaire des interfaces qu'ils implémentent. L'implémentation d'une interface introduit la cohésion comme une conséquence naturelle.

Bien qu'il ne soit pas réaliste dans certains senarios, il devrait être un objectif de conception à travailler.

Exemple (très sommaire):

public interface IStackoverFlowQuestion
      void SetAnswered(IUserProfile user);
      void VoteUp(IUserProfile user);
      void VoteDown(IUserProfile user);
}

public class NormalQuestion implements IStackoverflowQuestion {
      protected Integer vote_ = new Integer(0);
      protected IUserProfile user_ = null;
      protected IUserProfile answered_ = null;

      public void VoteUp(IUserProfile user) {
           vote_++;
           // code to ... add to user profile
      }

      public void VoteDown(IUserProfile user) {
          decrement and update profile
      }

      public SetAnswered(IUserProfile answer) {
           answered_ = answer
           // update u
      }
}

public class CommunityWikiQuestion implements IStackoverflowQuestion {
     public void VoteUp(IUserProfile user) { // do not update profile }
     public void VoteDown(IUserProfile user) { // do not update profile }
     public void SetAnswered(IUserProfile user) { // do not update profile }
}

À un autre endroit de votre base de code, vous pourriez avoir un module qui traite les questions indépendamment de ce qu'elles sont:

public class OtherModuleProcessor {
    public void Process(List<IStackoverflowQuestion> questions) {
       ... process each question.
    }
}

28

la meilleure explication de la cohésion vient du code propre de l'oncle Bob:

Les classes doivent avoir un petit nombre de variables d'instance. Chacune des méthodes d'une classe doit manipuler une ou plusieurs de ces variables. En général, plus une méthode manipule de variables, plus cette méthode est cohérente avec sa classe . Une classe dans laquelle chaque variable est utilisée par chaque méthode est au maximum cohérente.

En général, il n'est ni conseillé ni possible de créer de telles classes à cohésion maximale; d'autre part, nous souhaitons une cohésion élevée . Lorsque la cohésion est élevée, cela signifie que les méthodes et les variables de la classe sont co-dépendantes et s'unissent comme un tout logique.

La stratégie consistant à garder les fonctions petites et à garder les listes de paramètres courtes peut parfois conduire à une prolifération de variables d'instance qui sont utilisées par un sous-ensemble de méthodes. Lorsque cela se produit, cela signifie presque toujours qu'il y a au moins une autre classe qui essaie de sortir de la plus grande classe. Vous devez essayer de séparer les variables et les méthodes en deux ou plusieurs classes afin que les nouvelles classes soient plus cohérentes.


Je suis d'accord que c'est probablement la meilleure explication, c'est ce que j'aime chez Oncle Bob, qu'il peut expliquer le sens réel en quelques phrases. Connaissant cette définition, vous pouvez voir instantanément ce qui devrait être fait à une classe donnée pour augmenter sa cohésion.
Pawel Dubiel

13

simplement, la cohésion représente le degré auquel une partie d'une base de code forme une unité atomique logiquement unique. Couplage , d'autre part, représente le degré auquel une seule unité est indépendante des autres. En d'autres termes, c'est le nombre de connexions entre deux ou plusieurs unités. Plus le nombre est faible, plus le couplage est faible.

En substance, une cohésion élevée signifie conserver les parties d'une base de code qui sont liées les unes aux autres en un seul endroit. Le faible couplage, en même temps, consiste à séparer autant que possible les parties non liées de la base de code.

Types de code du point de vue de la cohésion et du couplage:

Idéal est le code qui suit la directive. Il est faiblement couplé et très cohésif. Nous pouvons illustrer un tel code avec cette image:entrez la description de l'image ici

God Object est le résultat de l'introduction d'une cohésion élevée et d'un couplage élevé. C'est un anti-modèle et représente essentiellement un seul morceau de code qui fait tout le travail à la fois: mal sélectionné a lieu lorsque les frontières entre les différentes classes ou modules sont mal sélectionnéesentrez la description de l'image ici entrez la description de l'image ici

Le découplage destructif est le plus intéressant. Cela se produit parfois lorsqu'un programmeur essaie de découpler une base de code à tel point que le code perd complètement son focus:entrez la description de l'image ici

en savoir plus ici


1
Excellent article et les illustrations! Si je peux suggérer une amélioration à une seule pensée, j'aime la façon dont les `` mal sélectionnés '' maintiennent les groupes de composants avec une sémantique sans rapport dans de petits essaims, mais je pense qu'ils devraient avoir visiblement plus de flèches entre eux. Après tout, même sur vos graphiques à 4 carrés, c'est celui qui tombe dans la plage supérieure de l'axe `` Couplage ''.
Slawomir Brzezinski

1
Je dirais également que «mal sélectionné» devrait avoir moins de flèches à l'intérieur de chaque essaim. L'utilisation de l'exemple de «structure de dossiers» de votre article, que vous classerez comme des référentiels ou des usines «mal sélectionnés», ne se parlera certainement pas.
Slawomir Brzezinski

MISE À JOUR: J'ai fait part de ces suggestions à l'auteur original de l'image et l'auteur était d'accord avec elles .
Slawomir Brzezinski

11

La cohésion en génie logiciel est le degré auquel les éléments d'un certain module vont ensemble. Ainsi, c'est une mesure de la forte corrélation de chaque fonctionnalité exprimée par le code source d'un module logiciel.

Le couplage en mots simples, c'est combien un composant (encore une fois, imaginez une classe, mais pas nécessairement) connaît le fonctionnement interne ou les éléments internes d'un autre, c'est-à-dire la connaissance qu'il a de l'autre composant.

J'ai écrit un article de blog à ce sujet , si vous voulez en savoir un peu plus avec des exemples et des dessins. Je pense que cela répond à la plupart de vos questions.


4

entrez la description de l'image ici

la cohésion fait référence à la façon dont une classe unique est conçue. La cohésion est le principe orienté objet le plus étroitement associé au fait de s'assurer qu'une classe est conçue avec un seul objectif bien ciblé. Plus une classe est ciblée, plus sa cohésion est grande. Les avantages d'une cohésion élevée sont que ces classes sont beaucoup plus faciles à maintenir (et moins fréquemment modifiées) que les classes à faible cohésion. Un autre avantage d'une cohésion élevée est que les classes ayant un objectif bien ciblé ont tendance à être plus réutilisables que les autres classes.

Dans l'image ci-dessus, nous pouvons voir qu'en faible cohésion, une seule classe est responsable de l'exécution de nombreux travaux qui ne sont pas en commun, ce qui réduit les chances de réutilisation et de maintenance. Mais dans une forte cohésion, il existe une classe distincte pour tous les travaux afin d'exécuter un travail spécifique, ce qui améliore la convivialité et la maintenance.


2

Cohésion (Co-hesion): Co qui signifie ensemble , hesion qui signifie coller . Le système de collage des particules de différentes substances.

Pour un exemple concret : img Courtoisie
entrez la description de l'image ici

Le tout est supérieur à la somme des parties -Aristote.

  • La cohésion est un type de mesure ordinale et est généralement décrite comme «haute cohésion» ou «faible cohésion». Les modules à forte cohésion ont tendance à être préférables, car une forte cohésion est associée à plusieurs caractéristiques souhaitables des logiciels, notamment la robustesse, la fiabilité, la réutilisabilité et la compréhensibilité. En revanche, une faible cohésion est associée à des traits indésirables tels que la difficulté à maintenir, tester, réutiliser ou même comprendre. wiki

  • Le couplage est généralement contrasté avec la cohésion . Un faible couplage est souvent en corrélation avec une cohésion élevée et vice versa. Un faible couplage est souvent le signe d'un système informatique bien structuré et d'une bonne conception, et lorsqu'il est combiné avec une cohésion élevée, il soutient les objectifs généraux de haute lisibilité et maintenabilité. wiki


1

Je pense que les différences peuvent être formulées comme suit:

  • La cohésion représente le degré auquel une partie d'une base de code forme une unité atomique logiquement unique.
  • Le couplage représente le degré auquel une seule unité est indépendante des autres.
  • Il est impossible d'archiver un découplage complet sans endommager la cohésion, et vice versa.

Dans cet article de blog, j'écris à ce sujet plus en détail.


1

La cohésion est une indication de la force fonctionnelle relative d'un module.

  • Un module cohérent effectue une seule tâche, nécessitant peu d'interaction avec d'autres composants dans d'autres parties d'un programme. En termes simples, un module cohérent ne devrait (idéalement) faire qu'une seule chose.
  • Vue conventionnelle:

    la «détermination» d'un module

  • Vue OO:

    La cohésion implique qu'un composant ou une classe encapsule uniquement des attributs et des opérations qui sont étroitement liés les uns aux autres et à la classe ou au composant lui-même

  • Niveaux de cohésion

    Fonctionnel

    Couche

    Communicationnel

    Séquentiel

    Procédure

    Temporel

    utilité

Le couplage est une indication de l'interdépendance relative entre les modules.

  • Le couplage dépend de la complexité de l'interface entre les modules, du point auquel l'entrée ou la référence est faite à un module et des données qui traversent l'interface.

  • Vue conventionnelle: degré auquel un composant est connecté à d'autres composants et au monde extérieur

  • Vue OO: une mesure qualitative du degré de connexion des classes entre elles

  • Niveau de couplage

    Contenu

     Commun

    Contrôle

     Tampon

    Données

    Appel de routine

    Type utilisation

    Inclusion ou importation

    Externe #


1

Couplage = interaction / relation entre deux modules ... Cohésion = interaction entre deux éléments au sein d'un module.

Un logiciel est composé de nombreux modules. Le module est composé d'éléments. Considérons qu'un module est un programme. Une fonction dans un programme est un élément.

Au moment de l'exécution, la sortie d'un programme est utilisée comme entrée pour un autre programme. C'est ce qu'on appelle l'interaction module à module ou processus pour traiter la communication. Ceci est également appelé couplage.

Dans un seul programme, la sortie d'une fonction est passée à une autre fonction. C'est ce qu'on appelle l'interaction d'éléments au sein d'un module. Ceci est également appelé cohésion.

Exemple:

Couplage = communication entre 2 familles différentes ... Cohésion = communication entre père-mère-enfant au sein d'une famille.


1
Alors, comment les expliquez-
Itban Saeed

Un logiciel est composé de nombreux modules. Le module est composé d'éléments. Considérons qu'un module est un programme. Une fonction dans un programme est un élément.
Dipankar Nalui

1

En termes simples, la cohésion signifie qu'une classe doit représenter un concept unique.

L'interface publique d'une classe est cohérente si toutes les fonctionnalités de la classe sont liées au concept que la classe représente. Par exemple, au lieu d'avoir la classe CashRegister, la cohésion des fonctionnalités CashRegister et Coin en fait deux classes - la classe CashRegister et Coin.

En couplage , une classe dépend d'une autre car elle utilise les objets de la classe.

Le problème avec un couplage élevé est qu'il peut créer des effets secondaires. Un changement dans une classe peut provoquer une erreur inattendue dans l'autre classe et peut casser tout le code.

Généralement, une cohésion élevée et un faible couplage sont considérés comme des POO de haute qualité.


0

Le terme cohésion est en effet un peu contre-intuitif pour ce qu'il signifie dans la conception de logiciels.

Le sens commun de la cohésion est que quelque chose qui colle bien, est uni, qui se caractérise par une liaison forte comme l'attraction moléculaire. Cependant, dans la conception de logiciels, cela signifie rechercher une classe qui, idéalement, ne fait qu'une seule chose, donc plusieurs sous-modules ne sont même pas impliqués.

Peut-être pouvons-nous y penser de cette façon. Une pièce a le plus de cohésion quand elle est la seule pièce (ne fait qu'une chose et ne peut pas être décomposée plus loin). C'est ce qui est souhaité dans la conception de logiciels. La cohésion est simplement un autre nom pour «responsabilité unique» ou «séparation des préoccupations».

Le terme couplage sur la main est assez intuitif, ce qui signifie qu'un module ne dépend pas d'un trop grand nombre d'autres modules et que ceux avec lesquels il se connecte peuvent être facilement remplacés, par exemple en obéissant au principe de substitution liskov .


Pourquoi les gens continuent-ils à utiliser le module Word au lieu de la classe?
northerner

1
@northerner est son terme juste plus générique.
zar

0

Différence de théorie

Cohésion

  • La cohésion est une indication de la force fonctionnelle relative du module.
  • Un module cohérent effectue une seule tâche, nécessitant peu d'interaction avec d'autres composants dans d'autres parties du programme.
  • Un module ayant une cohésion élevée et un faible couplage est dit fonctionnellement indépendant des autres modules.

Classification de cohésion

1. Coïncidentiel 2.Logique 3.Temporel 4.Procédural 5.Communication 6.Séquentiel 7.Fonctionnel

Couplage

  • Le couplage indique une relative interdépendance entre les modules.
  • Le degré de couplage entre deux modules dépend de leur complexité d'interface.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.