SlideShare une entreprise Scribd logo
1  sur  14
PRESENTATION SUR:
COHÉSION ET COUPLAGE
PRESENTER PAR:
HARRAK Ahmed(MQL)
PLAN
 Introduction : Le couplage et la cohésion
 La notion de cohésion
 Niveaux de cohésion
 Formes de cohésion dans la POO
 La cohésion appliquée à une classe
 La notion de couplage
 Niveaux de couplage
 L'importance de contrôler le couplage au niveau
de la classe
 La différence Entre la Cohésion et le Couplage
INTRODUCTION : LE COUPLAGE ET LA COHÉSION
Le couplage et la cohésion sont deux concepts
trouvés en Java (et tous les autres langages orientés
objet). Le couplage mesure dans quelle mesure chacun
des modules du programme dépend des autres modules
du programme. La cohésion mesure la relation entre
chacune des fonctions dans un module. En réalité, tout
langage orienté objet (y compris Java) a pour objectif
principal d’augmenter la cohésion et de diminuer le
couplage en même temps, afin de développer les
programmes les plus efficaces. Larry Constantine a mis au
point ces deux paramètres de génie logiciel afin de réduire
les coûts de modification et de maintenance des logiciels..
LA NOTION DE COHÉSION
La cohésion est un principe de conception informatique définissant un degré d'accord entre
les différents éléments d'un module. Selon Larman1, un module cohérent a ses éléments
étroitement liés et effectuant un nombre réduit d'opérations. Des modules peu cohérents sont
généralement difficiles à comprendre, à réutiliser et à maintenir, et sont fragiles, puisqu'ils sont
affectés par les modifications apportées aux autres modules.
La cohésion peut être une métrique mesurant l'application des principes d'encapsulation des
données et de masquage de l'information. Elle mesure également la cohésion sémantique des
interfaces des modules et des classes.
Donc,
Cohésion = interaction entre deux éléments dans un module
NIVEAUX DE COHÉSION
Selon Pressman, il existe sept niveaux de cohésion :
 Accidentel : décrivant le niveau le plus faible où le lien entre les différentes méthodes est inexistant
ou bien créé sur la base d'un critère futile.
 Logique : lorsque les méthodes sont reliées logiquement par un ou plusieurs critères communs.
 Temporel : lorsque les méthodes doivent être appelées au cours de la même période de temps.
 Procédural : lorsque les méthodes doivent être appelées dans un ordre spécifique.
 Communicationnel : lorsque les méthodes manipulent le même ensemble spécifique de données.
 Séquentiel : lorsque les méthodes qui manipulent le même ensemble de données doivent être
appelées dans un ordre spécifique.
 Fonctionnel : réalise le niveau le plus élevé lorsque la classe ou le module est dédié à une seule et
unique tâche bien spécifique.
Le niveau accidentel est celui de plus faible cohésion, le niveau fonctionnel celui de plus forte cohésion ;
une bonne architecture logicielle nécessite la plus forte cohésion possible.
NIVEAUX DE COHÉSION
Exemple : faible/ forte cohésion
Dans l'image à gauche de celui-ci,
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.
FORMES DE COHÉSION DANS LA POO
Dans la POO, on petit identifier plusieurs formes de cohésion : la cohésion entre les
méthodes, la cohésion entre les classes et la cohésion au niveau de l'héritage |Eder et al. 1995).
La cohésion entre les méthodes est. une adaptation du concept (h; cohésion appliqué aux
procédures et aux fonctions dans la programmation procédurale, tout en tenant compte que les
instructions d'une méthode sont liées à des variables et des attributs de classe. Au niveau de la
classe, la cohésion s'applique à la relation entre les méthodes et les attributs. La cohésion dans
l'héritage se réfère à la cohésion de classes, mais en prenant en considération les éléments
hérités. Préalable à toute analyse de cohésion, toutes les variables d'instance doivent être
déclarées « private ».
LA COHÉSION APPLIQUÉE À UNE CLASSE
Dans la programmation orientée objet, l'unité fondamentale est la classe. Elle combine l'état et le
comportement de la représentation d'un concept. La classe est composée des méthodes qui fournissent, le
comportement et des attributs qui gardent l'état. L'idée est que les méthodes de la classe traitent, ses
attributs. C'est-à-dire que les méthodes et les attributs devraient avoir un lion étroit. Le degré d'association
entre ces composants détermine la cohésion de la classe. Ainsi. |Bieman et Kang, 1995| définissent la
cohésion d'une classe comme une caractéristique concernant la connectivité entre les membres de la classe.
Lorsque le degré de cohésion d'une; classe est élevé, ses membres sont fortement liés et en théorie la
classe devrait, décrire de manière appropriée le concept qu'elle représente. Un haut degré de cohésion de
la classe est souhaitable, car elle favorise l'encapsulation et la réutilisation. D'ailleurs, la classe avec une
cohésion forte est plus facile à comprendre, étant donné qu'elle a un but bien spécifique. À l'inverse, une
classe sans cohésion est difficile à maintenir, à comprendre et à réutiliser. Elle est globalement plus fragile
et sensible à la variation.
Le manque de cohésion dans une classe peut indiquer la présence d'un problème de conception. C'est
un signe que les responsabilités ont été distribuées de manière inappropriée. Il est probable que la classe
contient seulement de l'information. Dans tel cas, la classe serait constituée par des attributs et contiendrait,
peu de méthodes pour traiter les attributs. Au contraire, il est possible que la classe soit, constituée par des
méthodes qui sont utilisées par d'autres classes.
LA NOTION DE COUPLAGE
Le couplage mesure dans quelle mesure chacun des modules du programme dépend des
autres modules du programme. Les interactions entre deux objets se produisent parce qu'il y a un
couplage. Les programmes faiblement couplés offrent une grande flexibilité et extensibilité. Le
couplage fort n'est jamais bon, car un objet peut être fortement dépendant d'un autre objet. C'est
un cauchemar lorsque le code est modifié, car un couplage élevé signifie que les programmeurs
doivent travailler sur plusieurs emplacements de code, même pour une seule modification
comportementale. Un couplage fort conduit toujours à des programmes avec une flexibilité faible et
une évolutivité / extensibilité moindre. Cependant, dans des langages de programmation tels que
Java, il est impossible d'éviter tout couplage. Mais il est recommandé aux programmeurs de tout
faire pour réduire le plus possible le couplage. Il est également possible d'avoir un couplage pour
aider les objets à interagir les uns avec les autres sans entraver son évolutivité et sa flexibilité.
Donc,
Couplage = les interactions /relations entre les deux modules
NIVEAUX DE COUPLAGE
Selon Pressman, il existe sept niveaux de couplage, du plus faible au plus fort :
 Sans couplage : les composants n'échangent pas d'information.
 Par données : les composants échangent de l'information par des méthodes utilisant des arguments
(paramètres) de type simple (nombre, chaîne de caractères, tableau).
 Par paquet : les composants échangent de l'information par des méthodes utilisant des arguments de
type composé (structure, classe).
 Par contrôle : les composants se passent ou modifient leur contrôle par changement d'un drapeau
(verrou).
 Externe : les composants échangent de l'information par un moyen de communication externe (fichier,
pipeline, lien de communication).
 Commun (global) : les composants échangent de l'information via un ensemble de données (variables)
commun.
 Par contenu (interne) : les composants échangent de l'information en lisant et écrivant directement dans
leurs espaces de données (variables) respectifs.
Une bonne architecture logicielle nécessite le couplage le plus faible possible.
NIVEAUX DE COUPLAGE
Exemple : faible couplage Exemple : forte couplage
L'IMPORTANCE DE CONTRÔLER LE COUPLAGE AU NIVEAU
DE LA CLASSE
Assurer le couplage faible entre classes est considéré comme une bonne pratique dans un projet
logiciel. Les classes sont couplées par les invocations qui se font entre elles. Un fort couplage indique que
les classes seront moins faciles à maintenir. Les classes auront une réutilisabilité diminuée et seront plus
complexes et plus difficiles à comprendre. En outre, tester des classes trop couplées est plus compliqué. Par
exemple, créer des objets factices pour faire les tests lorsque les objets sont fortement couplés produit une
complexité additionnelle augmentant la difficulté de tester un système. Au contraire, le couplage faible
entre classes donne les avantages suivants :
 Il simplifie la complexité dans la classe donc le code source est plus facile à lire,
 Il permet que les classes soient plus faciles à utiliser par les autres développeurs,
 Il permet de confiner les modifications potentielles à une petite zone de code.
Le couplage a été identifié connue un bon indicateur de l'aptitude d'un système à être changé. 11
favorise de manière substantielle la maintenance du logiciel. Cependant dans une application orientée
objet, les classes sont créées pour partager l'information entre elles. Les références externes, à travers
lesquelles le code d'une classe fait référence à une partie du code d'une autre classe, sont absolument
nécessaires. En conséquence, il y aura un certain niveau de couplage entre les classes qui composent une
application. Donc, dans la pratique l'idée est de maintenir le partage d'informations entre les classes à un
niveau raisonnable.
LA DIFFÉRENCE ENTRE LA COHÉSION ET LE COUPLAGE
Cohésion Couplage
La cohésion est l'indication de la relation au sein du
module.
Le couplage est l'indication des relations entre les
La cohésion montre la force fonctionnelle relative du
module.
Le couplage montre l'indépendance relative entre les
modules.
La cohésion est un degré (qualité) auquel un composant /
module se concentre sur une seule chose.
Le couplage est le degré auquel un composant / module
est connecté aux autres modules.
Lors de la conception, vous devez vous efforcer d'obtenir
une cohésion élevée, c'est-à-dire qu'un composant /
module cohésif se concentre sur une seule tâche (c'est-à-
dire une volonté unique) avec peu d'interaction avec les
autres modules du système.
Lors de la conception, vous devez vous efforcer d'obtenir
un faible couplage, c'est-à-dire que la dépendance entre
les modules doit être moindre.
La cohésion est le type d'extension naturelle du
des données, par exemple, une classe ayant tous les
membres visibles avec un package ayant une visibilité par
défaut.
La création de champs privés, de méthodes privées et de
classes non publiques fournit un couplage lâche.
La cohésion est un concept intra-module. Le couplage est un concept inter-module.
MERCI DE
VOTRE
ATTENTION

Contenu connexe

Tendances

Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Sofien Benrhouma
 

Tendances (20)

Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
 
Exercices uml-corrige
Exercices uml-corrigeExercices uml-corrige
Exercices uml-corrige
 
Base des données réparties
Base des données répartiesBase des données réparties
Base des données réparties
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data Processing
 
Chapitre 2 complexité
Chapitre 2 complexitéChapitre 2 complexité
Chapitre 2 complexité
 
Talend
TalendTalend
Talend
 
BigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans HadoopBigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans Hadoop
 
Modele mvc
Modele mvcModele mvc
Modele mvc
 
Développement d'un site web jee de e commerce basé sur spring (m.youssfi)
Développement d'un site web jee de e commerce basé sur spring (m.youssfi)Développement d'un site web jee de e commerce basé sur spring (m.youssfi)
Développement d'un site web jee de e commerce basé sur spring (m.youssfi)
 
Support programmation orientée objet c# .net version f8
Support programmation orientée objet c#  .net version f8Support programmation orientée objet c#  .net version f8
Support programmation orientée objet c# .net version f8
 
Support de cours Spring M.youssfi
Support de cours Spring  M.youssfiSupport de cours Spring  M.youssfi
Support de cours Spring M.youssfi
 
Telecharger Exercices corrigés PL/SQL
Telecharger Exercices corrigés PL/SQLTelecharger Exercices corrigés PL/SQL
Telecharger Exercices corrigés PL/SQL
 
UML Diagrammes Statiques
UML Diagrammes StatiquesUML Diagrammes Statiques
UML Diagrammes Statiques
 
Chp2 - SOA
Chp2 - SOAChp2 - SOA
Chp2 - SOA
 
Méthodologie 2 Track Unified Process
Méthodologie 2 Track Unified ProcessMéthodologie 2 Track Unified Process
Méthodologie 2 Track Unified Process
 
Design Patterns
Design PatternsDesign Patterns
Design Patterns
 
Présentation SOA
Présentation SOAPrésentation SOA
Présentation SOA
 
Manuel des TP : Atelier Web 2
Manuel des TP : Atelier Web 2Manuel des TP : Atelier Web 2
Manuel des TP : Atelier Web 2
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 

Similaire à Cohesion et couplage

Diagramme de classe
Diagramme de classeDiagramme de classe
Diagramme de classe
Ilhem Daoudi
 
Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...
Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...
Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...
JUSTINDAVONDAMBAT
 

Similaire à Cohesion et couplage (15)

.NET
.NET.NET
.NET
 
Architecture Logiciel_GRASP11111111.pptx
Architecture Logiciel_GRASP11111111.pptxArchitecture Logiciel_GRASP11111111.pptx
Architecture Logiciel_GRASP11111111.pptx
 
Cours partie1 elgarrai zineb
Cours partie1 elgarrai zinebCours partie1 elgarrai zineb
Cours partie1 elgarrai zineb
 
Design patterns
Design patternsDesign patterns
Design patterns
 
Design patterns
Design patternsDesign patterns
Design patterns
 
CPOO.pdf
CPOO.pdfCPOO.pdf
CPOO.pdf
 
SCORM
SCORMSCORM
SCORM
 
La théorie qui sous-tend les cartes conceptuelles et la façon de les construire
La théorie qui sous-tend les cartes conceptuelles et la façon de les construireLa théorie qui sous-tend les cartes conceptuelles et la façon de les construire
La théorie qui sous-tend les cartes conceptuelles et la façon de les construire
 
Apprentissage du java
Apprentissage du javaApprentissage du java
Apprentissage du java
 
Diagramme de classe
Diagramme de classeDiagramme de classe
Diagramme de classe
 
le NLP à l'ére de l'IA
le NLP à l'ére de l'IAle NLP à l'ére de l'IA
le NLP à l'ére de l'IA
 
Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...
Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...
Sinitier_a_la_programmation_et_a_loriente_objet__avec_des_exemples_en_C_C_C_J...
 
Design Patterns Java
Design Patterns JavaDesign Patterns Java
Design Patterns Java
 
Séminaire Inria IST - Référentiels et interoperabilité (2)
Séminaire Inria IST - Référentiels et interoperabilité (2)Séminaire Inria IST - Référentiels et interoperabilité (2)
Séminaire Inria IST - Référentiels et interoperabilité (2)
 
Referentiel
ReferentielReferentiel
Referentiel
 

Cohesion et couplage

  • 1. PRESENTATION SUR: COHÉSION ET COUPLAGE PRESENTER PAR: HARRAK Ahmed(MQL)
  • 2. PLAN  Introduction : Le couplage et la cohésion  La notion de cohésion  Niveaux de cohésion  Formes de cohésion dans la POO  La cohésion appliquée à une classe  La notion de couplage  Niveaux de couplage  L'importance de contrôler le couplage au niveau de la classe  La différence Entre la Cohésion et le Couplage
  • 3. INTRODUCTION : LE COUPLAGE ET LA COHÉSION Le couplage et la cohésion sont deux concepts trouvés en Java (et tous les autres langages orientés objet). Le couplage mesure dans quelle mesure chacun des modules du programme dépend des autres modules du programme. La cohésion mesure la relation entre chacune des fonctions dans un module. En réalité, tout langage orienté objet (y compris Java) a pour objectif principal d’augmenter la cohésion et de diminuer le couplage en même temps, afin de développer les programmes les plus efficaces. Larry Constantine a mis au point ces deux paramètres de génie logiciel afin de réduire les coûts de modification et de maintenance des logiciels..
  • 4. LA NOTION DE COHÉSION La cohésion est un principe de conception informatique définissant un degré d'accord entre les différents éléments d'un module. Selon Larman1, un module cohérent a ses éléments étroitement liés et effectuant un nombre réduit d'opérations. Des modules peu cohérents sont généralement difficiles à comprendre, à réutiliser et à maintenir, et sont fragiles, puisqu'ils sont affectés par les modifications apportées aux autres modules. La cohésion peut être une métrique mesurant l'application des principes d'encapsulation des données et de masquage de l'information. Elle mesure également la cohésion sémantique des interfaces des modules et des classes. Donc, Cohésion = interaction entre deux éléments dans un module
  • 5. NIVEAUX DE COHÉSION Selon Pressman, il existe sept niveaux de cohésion :  Accidentel : décrivant le niveau le plus faible où le lien entre les différentes méthodes est inexistant ou bien créé sur la base d'un critère futile.  Logique : lorsque les méthodes sont reliées logiquement par un ou plusieurs critères communs.  Temporel : lorsque les méthodes doivent être appelées au cours de la même période de temps.  Procédural : lorsque les méthodes doivent être appelées dans un ordre spécifique.  Communicationnel : lorsque les méthodes manipulent le même ensemble spécifique de données.  Séquentiel : lorsque les méthodes qui manipulent le même ensemble de données doivent être appelées dans un ordre spécifique.  Fonctionnel : réalise le niveau le plus élevé lorsque la classe ou le module est dédié à une seule et unique tâche bien spécifique. Le niveau accidentel est celui de plus faible cohésion, le niveau fonctionnel celui de plus forte cohésion ; une bonne architecture logicielle nécessite la plus forte cohésion possible.
  • 6. NIVEAUX DE COHÉSION Exemple : faible/ forte cohésion Dans l'image à gauche de celui-ci, 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.
  • 7. FORMES DE COHÉSION DANS LA POO Dans la POO, on petit identifier plusieurs formes de cohésion : la cohésion entre les méthodes, la cohésion entre les classes et la cohésion au niveau de l'héritage |Eder et al. 1995). La cohésion entre les méthodes est. une adaptation du concept (h; cohésion appliqué aux procédures et aux fonctions dans la programmation procédurale, tout en tenant compte que les instructions d'une méthode sont liées à des variables et des attributs de classe. Au niveau de la classe, la cohésion s'applique à la relation entre les méthodes et les attributs. La cohésion dans l'héritage se réfère à la cohésion de classes, mais en prenant en considération les éléments hérités. Préalable à toute analyse de cohésion, toutes les variables d'instance doivent être déclarées « private ».
  • 8. LA COHÉSION APPLIQUÉE À UNE CLASSE Dans la programmation orientée objet, l'unité fondamentale est la classe. Elle combine l'état et le comportement de la représentation d'un concept. La classe est composée des méthodes qui fournissent, le comportement et des attributs qui gardent l'état. L'idée est que les méthodes de la classe traitent, ses attributs. C'est-à-dire que les méthodes et les attributs devraient avoir un lion étroit. Le degré d'association entre ces composants détermine la cohésion de la classe. Ainsi. |Bieman et Kang, 1995| définissent la cohésion d'une classe comme une caractéristique concernant la connectivité entre les membres de la classe. Lorsque le degré de cohésion d'une; classe est élevé, ses membres sont fortement liés et en théorie la classe devrait, décrire de manière appropriée le concept qu'elle représente. Un haut degré de cohésion de la classe est souhaitable, car elle favorise l'encapsulation et la réutilisation. D'ailleurs, la classe avec une cohésion forte est plus facile à comprendre, étant donné qu'elle a un but bien spécifique. À l'inverse, une classe sans cohésion est difficile à maintenir, à comprendre et à réutiliser. Elle est globalement plus fragile et sensible à la variation. Le manque de cohésion dans une classe peut indiquer la présence d'un problème de conception. C'est un signe que les responsabilités ont été distribuées de manière inappropriée. Il est probable que la classe contient seulement de l'information. Dans tel cas, la classe serait constituée par des attributs et contiendrait, peu de méthodes pour traiter les attributs. Au contraire, il est possible que la classe soit, constituée par des méthodes qui sont utilisées par d'autres classes.
  • 9. LA NOTION DE COUPLAGE Le couplage mesure dans quelle mesure chacun des modules du programme dépend des autres modules du programme. Les interactions entre deux objets se produisent parce qu'il y a un couplage. Les programmes faiblement couplés offrent une grande flexibilité et extensibilité. Le couplage fort n'est jamais bon, car un objet peut être fortement dépendant d'un autre objet. C'est un cauchemar lorsque le code est modifié, car un couplage élevé signifie que les programmeurs doivent travailler sur plusieurs emplacements de code, même pour une seule modification comportementale. Un couplage fort conduit toujours à des programmes avec une flexibilité faible et une évolutivité / extensibilité moindre. Cependant, dans des langages de programmation tels que Java, il est impossible d'éviter tout couplage. Mais il est recommandé aux programmeurs de tout faire pour réduire le plus possible le couplage. Il est également possible d'avoir un couplage pour aider les objets à interagir les uns avec les autres sans entraver son évolutivité et sa flexibilité. Donc, Couplage = les interactions /relations entre les deux modules
  • 10. NIVEAUX DE COUPLAGE Selon Pressman, il existe sept niveaux de couplage, du plus faible au plus fort :  Sans couplage : les composants n'échangent pas d'information.  Par données : les composants échangent de l'information par des méthodes utilisant des arguments (paramètres) de type simple (nombre, chaîne de caractères, tableau).  Par paquet : les composants échangent de l'information par des méthodes utilisant des arguments de type composé (structure, classe).  Par contrôle : les composants se passent ou modifient leur contrôle par changement d'un drapeau (verrou).  Externe : les composants échangent de l'information par un moyen de communication externe (fichier, pipeline, lien de communication).  Commun (global) : les composants échangent de l'information via un ensemble de données (variables) commun.  Par contenu (interne) : les composants échangent de l'information en lisant et écrivant directement dans leurs espaces de données (variables) respectifs. Une bonne architecture logicielle nécessite le couplage le plus faible possible.
  • 11. NIVEAUX DE COUPLAGE Exemple : faible couplage Exemple : forte couplage
  • 12. L'IMPORTANCE DE CONTRÔLER LE COUPLAGE AU NIVEAU DE LA CLASSE Assurer le couplage faible entre classes est considéré comme une bonne pratique dans un projet logiciel. Les classes sont couplées par les invocations qui se font entre elles. Un fort couplage indique que les classes seront moins faciles à maintenir. Les classes auront une réutilisabilité diminuée et seront plus complexes et plus difficiles à comprendre. En outre, tester des classes trop couplées est plus compliqué. Par exemple, créer des objets factices pour faire les tests lorsque les objets sont fortement couplés produit une complexité additionnelle augmentant la difficulté de tester un système. Au contraire, le couplage faible entre classes donne les avantages suivants :  Il simplifie la complexité dans la classe donc le code source est plus facile à lire,  Il permet que les classes soient plus faciles à utiliser par les autres développeurs,  Il permet de confiner les modifications potentielles à une petite zone de code. Le couplage a été identifié connue un bon indicateur de l'aptitude d'un système à être changé. 11 favorise de manière substantielle la maintenance du logiciel. Cependant dans une application orientée objet, les classes sont créées pour partager l'information entre elles. Les références externes, à travers lesquelles le code d'une classe fait référence à une partie du code d'une autre classe, sont absolument nécessaires. En conséquence, il y aura un certain niveau de couplage entre les classes qui composent une application. Donc, dans la pratique l'idée est de maintenir le partage d'informations entre les classes à un niveau raisonnable.
  • 13. LA DIFFÉRENCE ENTRE LA COHÉSION ET LE COUPLAGE Cohésion Couplage La cohésion est l'indication de la relation au sein du module. Le couplage est l'indication des relations entre les La cohésion montre la force fonctionnelle relative du module. Le couplage montre l'indépendance relative entre les modules. La cohésion est un degré (qualité) auquel un composant / module se concentre sur une seule chose. Le couplage est le degré auquel un composant / module est connecté aux autres modules. Lors de la conception, vous devez vous efforcer d'obtenir une cohésion élevée, c'est-à-dire qu'un composant / module cohésif se concentre sur une seule tâche (c'est-à- dire une volonté unique) avec peu d'interaction avec les autres modules du système. Lors de la conception, vous devez vous efforcer d'obtenir un faible couplage, c'est-à-dire que la dépendance entre les modules doit être moindre. La cohésion est le type d'extension naturelle du des données, par exemple, une classe ayant tous les membres visibles avec un package ayant une visibilité par défaut. La création de champs privés, de méthodes privées et de classes non publiques fournit un couplage lâche. La cohésion est un concept intra-module. Le couplage est un concept inter-module.