Différence entre cohésion et couplage
Quelle est la différence entre cohésion et couplage?
Comment le couplage et la cohésion peuvent-ils conduire à une conception de logiciel bonne ou mauvaise?
Quels sont quelques exemples décrivant la différence entre les deux et leur impact sur la qualité globale du code?
Cohésion fait référence à ce que la classe (ou le module) peut faire. Une cohésion faible signifierait que la classe accomplit 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 devrait faire, c’est-à-dire uniquement sur les méthodes relatives à l’intention de la classe.
Exemple de faible cohésion:
-------------------
| Staff |
-------------------
| checkEmail() |
| sendEmail() |
| emailValidate() |
| PrintLetter() |
-------------------
Exemple de grande cohésion:
----------------------------
| Staff |
----------------------------
| -salary |
| -emailAddr |
----------------------------
| setSalary(newSalary) |
| getSalary() |
| setEmailAddr(newEmail) |
| getEmailAddr() |
----------------------------
Quant à couplage , il fait référence à la relation entre deux classes/modules liés ou dépendants. Pour les classes faiblement couplées, changer quelque chose de majeur dans une classe ne devrait pas affecter l'autre. Un couplage élevé rendrait difficile la modification et la maintenance de votre code; comme les classes sont très unies, un changement peut nécessiter une refonte complète du système.
Une bonne conception logicielle a une grande cohésion et un faible couplage .
Une cohésion élevée dans les modules et un couplage faible entre modules sont souvent considérés comme liés à la haute qualité dans les 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 couplé aussi vaguement que possible au code des autres classes Java.
Le chapitre 3 de Construction de logiciels orientés objet de Meyer (2e édition) est une excellente description de ces problèmes.
La cohésion indique à quel point les responsabilités d'un élément logiciel sont liées et ciblées.
Coupling fait référence au degré de connexion d'un élément logiciel à 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 Cohésion élevée et supportent Couplage faible.
La faible cohésion donne lieu à des classes monolithiques difficiles à maintenir, à comprendre et à réduire la ré-utilisabilité. De même, High Coupling donne des classes étroitement couplées et les modifications apportées ne sont généralement pas non locales, difficiles à modifier et réduisent la réutilisation.
Nous pouvons prendre un scénario hypothétique dans lequel nous concevons un ConnectionPool pouvant être surveillé typique avec les exigences suivantes. Notez que cela peut sembler trop cher pour une classe simple telle que ConnectionPool, mais l’intention de base est simplement de démontrer faible couplage et haute cohésion avec un exemple simple et je pense que cela devrait aider.
- soutenir obtenir une connexion
- libérer une connexion
- obtenir des statistiques sur la connexion par rapport au nombre d'utilisations
- obtenir des statistiques sur la connexion par rapport au temps
- Stockez les informations de récupération et de libération de la connexion dans une base de données pour une génération ultérieure de rapports.
Avec low cohesion, nous pourrions concevoir une classe ConnectionPool en regroupant avec force toutes ces fonctionnalités/responsabilités dans une seule classe, comme indiqué 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 de la gestion des statistiques de connexion.
Avec haute cohésion, nous pouvons attribuer ces responsabilités à toutes les classes et les rendre plus faciles à gérer et à réutiliser.
Pour illustrer le couplage faible, nous poursuivons avec le diagramme ci-dessus à forte cohésion ConnectionPool. Si nous examinons le diagramme ci-dessus, même s'il supporte une cohésion élevée, le ConnectionPool est étroitement associé à la classe ConnectionStatistics et à PersistentStore, il interagit directement avec eux. Au lieu de cela, pour réduire le couplage, nous pourrions introduire une interface ConnectionListener et laisser ces deux classes l'implémenter et les laisser s'enregistrer avec la classe ConnectionPool. Et le ConnectionPool parcourra ces écouteurs et les notifiera des événements de connexion et de libération de connexion et permettra moins de couplage.
Note/Word ou Caution: Pour ce scénario simple, cela peut sembler excessif, mais si nous imaginons un scénario en temps réel dans lequel notre application doit interagir avec plusieurs services tiers pour effectuer une transaction: Coupler directement notre code avec les services tiers signifieraient que toute modification apportée au service tiers pourrait entraîner des modifications de notre code à plusieurs endroits. Nous pourrions plutôt avoir Facade qui interagit avec ces multiples services en interne et toute modification des services devient locale pour le Facade faible couplage avec les services tiers.
Cohesion est l'indication de la relation au sein de un module.
Coupling indique les relations entre les modules.
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 chose simple
- Lors de la conception, vous devez vous efforcer d'obtenir une cohésion élevée un composant/module cohérent se concentre sur une seule tâche (c'est-à-dire, avec un seul esprit) 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 pour Exemple: classe dont tous les membres sont visibles avec un package ayant une visibilité par défaut La cohésion est un concept intra-module.
Couplage
- Le couplage est l'indication des relations entre les modules.
- Le couplage montre l'indépendance relative entre les modules.
- Le couplage est le degré auquel un composant/module est connecté aux autres modules.
- Lors de la conception, vous devez rechercher un couplage faible, c’est-à-dire que la dépendance entre les modules doit être inférieure.
- Faire des champs privés, des méthodes privées et des classes non publiques fournit un couplage lâche.
- Le couplage est un concept inter-modules.
vérifier this link
Une cohésion accrue et un couplage réduit conduisent à une bonne conception logicielle.
Cohesion partitionne votre fonctionnalité de manière à ce qu'elle soit concise et proche des données qui la concernent, tandis que le découplage garantit que la mise en œuvre fonctionnelle est isolée du reste du système.
Découpler vous permet de modifier la mise en œuvre sans affecter les autres parties de votre logiciel.
Cohesion garantit que la mise en œuvre est plus spécifique à la fonctionnalité et, en même temps, plus facile à gérer.
La méthode la plus efficace pour diminuer le couplage et augmenter la cohésion est conception par interface .
C'est-à-dire que les objets fonctionnels majeurs ne doivent se "connaître" que par l'intermédiaire de l'interface (s) qu'ils implémentent. L'implémentation d'une interface introduit la cohésion comme conséquence naturelle.
Bien que cela ne soit pas réaliste dans certains scénarios, il devrait être un objectif de conception par lequel 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 }
}
Certains endroits de votre base de code pourraient 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.
}
}
la meilleure explication de cohésion provient du Clean Code 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 elle est cohérente avec sa classe. Une classe dans laquelle chaque variable est utilisée par chaque méthode est cohésive au maximum.
En général, il n'est ni conseillé ni possible de créer de telles classes à cohésion maximale; d'autre part, nous voudrions que la cohésion soit é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 forment un tout logique.
La stratégie consistant à garder les fonctions réduites et les listes de paramètres courtes peut parfois conduire à une prolifération de variables d'instance utilisées par un sous-ensemble de méthodes. Lorsque cela se produit, cela signifie presque toujours qu’au moins une autre classe tente de sortir de la classe supérieure. Vous devez essayer de séparer les variables et les méthodes en deux classes ou plus, de manière à ce que les nouvelles classes soient plus cohérentes.
La cohésion en génie logiciel est le degré d'appartenance des éléments d'un module donné. Ainsi, il s'agit d'une mesure de la relation étroite entre chaque élément de fonctionnalité exprimé par le code source d'un module logiciel.
Coupler en termes 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 combien il a la connaissance de l’autre composant.
J'ai écrit un article de blog à ce sujet , si vous voulez lire un peu plus de détails avec des exemples et des dessins. Je pense que cela répond à la plupart de vos questions.
la cohésion fait référence à la manière dont une classe 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 objectif unique et bien ciblé. Plus une classe est ciblée, plus sa cohésion est grande. Les avantages d'une forte cohésion sont que ces classes sont beaucoup plus faciles à maintenir (et moins fréquemment modifiées) que les classes à faible cohésion. Un autre avantage de la cohésion élevée est que les classes avec un objectif bien ciblé ont tendance à être plus réutilisables que les autres classes.
Dans l'image ci-dessus, nous pouvons voir que dans une cohésion faible, une seule classe est responsable de l'exécution de tâches non communes qui réduisent les chances de réutilisation et de maintenance. Cependant, dans le cas d'une cohésion élevée, il existe une classe distincte pour tous les travaux permettant d'exécuter un travail spécifique, ce qui entraîne une meilleure facilité d'utilisation et de maintenance.
Cohésion (Co-hesion): Co qui signifie ensemble, hesion qui signifie coller. Le système de collage de particules de différentes substances.
Pour des exemples concrets:
img Courtesy
Le total 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 une «cohésion élevée» ou une «cohésion faible». Les modules à forte cohésion tendent à être préférables, car une haute cohésion est associée à plusieurs caractéristiques souhaitables des logiciels, notamment la robustesse, la fiabilité, la réutilisation et la compréhensibilité. En revanche, une faible cohésion est associée à des caractéristiques indésirables telles qu’être difficile à maintenir, à tester, à réutiliser ou même à comprendre. wiki
Coupling est généralement comparé à cohésion. Un faible couplage est souvent lié à une cohésion élevée, et inversement. Un faible couplage est souvent le signe d'un système informatique bien structuré et d'une bonne conception. Combiné à une cohésion élevée, il contribue à la réalisation des objectifs généraux de lisibilité et de maintenabilité. wiki
Je pense que les différences peuvent être mises comme suit:
- La cohésion représente la mesure dans laquelle une partie d'une base de code forme une unité atomique logiquement unique.
- Le couplage indique à quel point une unité est indépendante des autres.
- Il est impossible d’archiver un découplage complet sans nuire à la cohésion, et inversement.
Dans cet article de blog J'écris à ce sujet plus en détail.
simplement, Cohesion représente le degré auquel une partie d'une base de code forme une unité atomique logiquement unique. Coupling, quant à lui, représente le degré d'indépendance d'une unité. En d'autres termes, il s'agit du nombre de connexions entre deux ou plusieurs unités. Plus le nombre est petit, plus le couplage est faible.
Par essence, une cohésion élevée signifie que les éléments d’une base de code qui sont liés les uns aux autres sont conservés au même endroit. Dans le même temps, un faible couplage consiste à séparer autant que possible des parties non liées de la base de code.
Types de code dans une perspective de cohésion et de couplage:
Idéal est le code qui suit la ligne directrice. Il est faiblement couplé et très cohésif. Nous pouvons illustrer ce code avec cette image: 
God Object résulte de l’introduction d’une cohésion élevée et d’un couplage élevé. C'est un anti-motif et représente fondamentalement un seul morceau de code qui fait tout le travail à la fois: 
mal sélectionné a lieu lorsque les limites entre différentes classes ou modules sont mal sélectionnées 
Le découplage destructif est le plus intéressant. Cela se produit parfois lorsqu'un programmeur essaie de découpler une base de code au point de perdre complètement le code: 
lire plus ici
Coupling = interaction/relation entre deux modules ...Cohesion = interaction entre deux éléments dans un module.
Un logiciel est composé de plusieurs modules. Le module est constitué d'éléments. Considérons 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. Ceci est appelé interaction entre modules ou processus pour traiter la communication. Ceci s'appelle également comme couplage.
Au sein d'un même programme, la sortie d'une fonction est transmise à une autre fonction. Ceci est appelé interaction d'éléments dans un module. Ceci s'appelle également comme cohésion.
Exemple:
Couplage = communication entre 2 familles différentes ... Cohésion = communication entre père-mère-enfant au sein d'une famille.
Cohesion est une indication de la force fonctionnelle relative d'un module.
- Un module cohésif effectue une tâche unique, nécessitant peu d'interaction avec d'autres composants des autres parties d'un programme. En résumé, un module cohésif ne devrait (idéalement) faire qu’une chose.
ViewVue conventionnelle:
la «monotonie» d'un module
OO vue:
La cohésion implique qu'un composant ou une classe n'encapsule que des attributs et des opérations étroitement liés les uns aux autres et à la classe ou au composant lui-même
Niveaux de cohésion
fonctionnel
couche
Communication
séquentiel
Procédure
EmporTemporel
Utilité
Coupling 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 transmises par l'interface.
Vue conventionnelle: Le degré de connexion d'un composant à d'autres composants et au monde extérieur
Vue OO: une mesure qualitative du degré de connexion des classes les unes aux autres
Niveau de couplage
Contenu
Commun
Contrôle
Stamp
Données
Out appel de routine
Type d'utilisation
Inclusion ou importation
Numéro externe
Le terme cohésion est en effet un peu contre-intuitif pour ce que cela signifie dans la conception de logiciels.
Le sens commun de la cohésion est que quelque chose qui unit bien est uni, qui sont caractérisés par un lien fort comme une attraction moléculaire. Cependant, dans la conception logicielle, cela signifie rechercher une classe qui, idéalement, ne fait qu'une chose, de sorte que plusieurs sous-modules ne sont même pas impliqués.
Peut-être pouvons-nous penser de cette façon. Une partie a le plus de cohésion quand elle est la seule (ne fait qu'une chose et ne peut pas être décomposée davantage). C'est ce que l'on souhaite 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 de trop d'autres modules et que ceux avec lesquels il se connecte peuvent être facilement remplacés, par exemple en obéissant à principe de substitution de liskov .
En termes simples, cohésion signifie qu'une classe doit représenter un seul concept.
L'interface publique d'une classe est cohérente si toutes les caractéristiques de la classe sont liées au concept représenté par la classe . Par exemple, au lieu d'avoir la classe CashRegister, la cohésion des fonctionnalités CashRegister et Coin en fait une classe: CashRegister et Coin classe.
Dans 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 endommager tout le code.
En règle générale, une cohésion élevée et un couplage faible sont considérés comme une POO de haute qualité.