[C++] Faible et fort couplage

Bonjour,

Je me permet de poser une question triviale mais je n'arrive pas à faire la différence entre un couplage fort et faible en deux classes malgré les ressources su Web.

Je sais juste que si A et B sont deux classes fortement couplées alors si on modifie A alors il faut modifier B mais je ne connais pas la définition d'un couplage faible (je ne sais pas si c'est l'inverse).

Est ce que ca serait possible d'avoir un exemple simple d'illustration du couplage fort et du couplage faible ?

Merci à vous :)

Le plus courant :

Héritage => couplage fort
Agrégation => couplage faible

un couplage fort est généralement a proscrire, en gros tes classes vont partagé des définitions spécifiques. Par exemple si tu dois faire une classe de tableau, pour stocker ta classe voiture, si tu n'utilise pas les templates ta classes tableau ne pourra être réutilisé dans un autre projet...

Ok donc si je comprends bien, quand on introduit des définitions de méthodes/attributs spécifique à une classe dans une autre classe alors on réalise un couplage fort ?

Vous n'auriez pas un exemple concret des deux concepts ? ;)

Exemple JAVA

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Abstract Class A{ private String[] A;   public String[] getElements(){   }   }     Class B extends A{ //j'hérite des méthodes de A public String[] getElementsB(){ this.getElements(); // A } }

---

Si je change l'impléméntation de A, j'impacte celle de B.
exemple passer à une collection ......

Mais si je fais ...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Abstract Class A{ private String[] A;   public String[] getElements(){   }   }     Class B{ //j'hérite des méthodes de A A a; String[] b; <- je peux garder sauf si je veux une collection, alors je change l'extraction des données(1). public String[] getElementsB(){<- je ne touche rien (couplage faible) a = new A[]; etc ..... (1)this.b = a.getElements(); // <= a changer pour une collection return this.b; } }

---

voila ;)

Voir design pattern composite ...

Olivier

Alors je vois bien l'héritage dans un cas et la composition dans l'autre mais par contre, je ne comprends pas comment on peut avoir un tableau de String nommé A dans la classe A !

Code:

---

1 2	Abstract Class A{ private String[] A;

---

Ca ne serait pas une erreur ?

Bonsoir,

Oui c'est une erreur de frappe, mais c'est possible, rien ne t'empêche d'avoir un objet qui référence un objet de même type, exemple contrainte d'intégrité référentielle.
Un individu est en lien avec un autre ou plusieurs individus ...


Olivier

Citation:

---

Envoyé par nathieb

Bonsoir,

Oui c'est une erreur de frappe, mais c'est possible, rien ne t'empêche d'avoir un objet qui référence un objet de même type, exemple contrainte d'intégrité référentielle.
Un individu est en lien avec un autre ou plusieurs individus ...


Olivier

---

Ok merci je vois mieux maintenant ;)

Le couplage entre deux classes A et B va décroissant selon leur relation :

• héritage (le plus fort) :
  
  Code:

  ---

  class A : public B

  ---

• composition :
  
  Code:

  ---

  1 2 3 4 5

  class A { B b; std::unique_ptr<B> b2; };

  ---

• agrégation :
  
  Code:

  ---

  1 2 3 4

  class A { std::weak_ptr<B> b; };

  ---

• association:
  
  Code:

  ---

  1 2 3 4

  class A { void do_something(B&); };

  ---

D'autres constructions jouent sur le couplage :

• Si A utilise une variable globale de type B, on introduit un couplage (fort? j'aurais tendance à le placer assez haut en tout cas)
• si A utilise (hormis dans le cas d'héritage) non pas directement B mais une classe 'abstraite' (*) implémentée dans B, on réduit le couplage entre A et B
  Code:

  ---

  1 2 3 4 5 6 7 8 9 10

  class Base_B; class A { std::unique_ptr<Base_B> b; // < qu'un std::unique_ptr<B> std::weak_ptr<Base_B> b; // < qu'un std::weak_ptr<B> void do_something(Base_B&); // < qu'un do_something(B&); };   class B : public Base B{};

  ---

• Le paramétrage générique peut affaiblir les différentes relations en permettant d'utiliser des policies pour adapter à la compilation l'interface de B à l'utilisation par A

(*) abstraite : disons dont l'interface est destinée à être redéfinie au besoin pas une classe dérivée.

Bonjour,

La c'est vraiment claire c'est ce que j'attendais en fait comme réponse ;)

Par contre, je n'utilise pas les pointeurs intelligent de Boost, je préfère manipuler les vrais pointeurs par habitude et puis je sais relativement bien les maitriser.

Donc quelle serait l'équivalent avec des pointeurs normaux (ou des références) de l'a composition et de l'agrégation ?

Code:

---

1 2 3

std::unique_ptr<B> b; // composition std::weak_ptr<B> b; // agrégation

---

Merci :)

Un pointeur nu n'a aucun moyen d'être équivalent à un de ces smart pointers. D'ailleurs, ils sont dans la STL, pas seulement dans boost.

Les pointeurs ne gèrent en eux mêmes pas la durée de vie de l'objet pointé, contrairement aux smart pointers...donc par exemple on ne verra pas au niveau d'un pointeur la nuance entre composition et agrégation, qui tient à la gestion de la durée de vie (être propriétaire d'un objet, dont on contrôle la durée de vie, contre avoir accès à un objet dont la durée de vie est gérée ailleurs).
Le pointeur recouvre donc les deux cas en terme de niveau de couplage, à mon avis. Sans information supplémentaire il est probablement sage de le considérer comme au même niveau de couplage que la composition.

Parfait, merci pour la précision :ccool:

Citation:

---

Envoyé par 3DArchi

• héritage (le plus fort) :
  
  Code:

  ---

  class A : public B

  ---

• composition :
  
  Code:

  ---

  1 2 3 4 5

  class A { B b; std::unique_ptr<B> b2; };

  ---

• agrégation :
  
  Code:

  ---

  1 2 3 4

  class A { std::weak_ptr<B> b; };

  ---

• association:
  
  Code:

  ---

  1 2 3 4

  class A { void do_something(B&); };

  ---

---

Cette description bijective très claire entre l'UML et le C++ est ce que j'ai très longtemps cherché à l'époque où j'apprenais l'UML.
Ça mériterait d'être mis dans la FAQ.

Citation:

---

Envoyé par oodini

Ça mériterait d'être mis dans la FAQ.

---

+1
Parfaitement d'accord

Le couplage, ce n'est pas aussi trivial que ce que le découpage pourrait laisser entendre.

Si les deux classes A et B ne peuvent pas être manipulées indépendamment l'une de l'autre (toutes les fonctions de A prennent un B et vice-versa), alors elles seront fortement couplées, explicitement. Variables globales et singletons (la même chose conceptuellement parlant) rajoutent bien un couplage, mais il est caché.
Ce que je veux dire c'est qu'il y a divers degrés de couplages qui font que 15
associations peuvent devenir aussi intenses qu'un héritage.

PS: OP, tu penses tout connaitre des pointeurs et ne pas avoir besoin des encapsulations qu'apportent le C++ ? Et comment en C++ nettoies-tu derrière toi quand il y a des exceptions ?

Citation:

---

Envoyé par Luc Hermitte

L
PS: OP, tu penses tout connaitre des pointeurs et ne pas avoir besoin des encapsulations qu'apportent le C++ ? Et comment en C++ nettoies-tu derrière toi quand il y a des exceptions ?

---

Tout connaitre non, mais une grande partie oui :)
Avec des deletes qui vont bien, je fais des tests de chaque allocation et si au run-time, une exception intervient alors je vais les delete qui vont bien dans le bon ordre. Valgrind m'a bien aidé dans toute cette histoire :mrgreen:

Salut,

Citation:

---

Envoyé par Luc Hermitte

PS: OP, tu penses tout connaitre des pointeurs et ne pas avoir besoin des encapsulations qu'apportent le C++ ? Et comment en C++ nettoies-tu derrière toi quand il y a des exceptions ?

---

Heu, je me fais un peu l'avocat du diable, mais, si on veille correctement à correctement déléguer les responsabilités et, entre autres, à ce que chaque fonction / classe ne gère qu'une ressource (ou plutot qu'un seul type de ressource) créée de manière dynamique le ménage se fait tout seul :D ;)

Citation:

---

Envoyé par Luc Hermitte

Le couplage, ce n'est pas aussi trivial que ce que le découpage pourrait laisser entendre.

---

Oui. Cela dépend aussi comment c'est mis en oeuvre (héritage ou générique) + comment la dépendance est injecté.

Citation:

---

Envoyé par Luc Hermitte

Variables globales et singletons (la même chose conceptuellement parlant) rajoutent bien un couplage, mais il est caché.

---

C'est pour cela que j'avais rajouté une nuance pour l'utilisation des variables globales. Ensuite, qu'elles soient globales, singleton, monostate, statique, on est d'accord pour dire que c'est à peu près la même chose

Citation:

---

Envoyé par Luc Hermitte

Si les deux classes A et B ne peuvent pas être manipulées indépendamment l'une de l'autre (toutes les fonctions de A prennent un B et vice-versa), alors elles seront fortement couplées, explicitement.

---

Oui, mais ça cache probablement un lien plus fort (composition/agrégation au moins dans un sens).



Si je reconnais que ce n'est pas aussi simple, ça peut néanmoins donner une indication si le lien est assez en adéquation avec son objectif.

Bonjour,

Dans une architecture découplée, fait éviter les variables globales.
Sinon je ne suis expert C++, mais pour rajouter des fonctionnalités autres
à une classe on utilise des décorateurs, visiteurs etc ...
Il faut passer ensuite à l'utilisation de design pattern, avec modération.
car trop de DP tue les temps de dev.

Olivier

Citation:

---

Envoyé par Aspic

Tout connaitre non, mais une grande partie oui :)
Avec des deletes qui vont bien, je fais des tests de chaque allocation et si au run-time, une exception intervient alors je vais les delete qui vont bien dans le bon ordre. Valgrind m'a bien aidé dans toute cette histoire :mrgreen:

---

La ou la RAII aurait tout fait toute seule ...

Citation:

---

Envoyé par koala01

Salut,Heu, je me fais un peu l'avocat du diable, mais, si on veille correctement à correctement déléguer les responsabilités et, entre autres, à ce que chaque fonction / classe ne gère qu'une ressource (ou plutot qu'un seul type de ressource) créée de manière dynamique le ménage se fait tout seul :D ;)

---

Je comprends, je me le fais souvent aussi.
Maintenant, sa réponse sentait l'ancienne école, d'où ma question. Je voulais vérifier s'il allait répondre RAII (à la main) ou tout autre chose. Et justement ...

Citation:

---

Envoyé par Aspic

Tout connaitre non, mais une grande partie oui :)
Avec des deletes qui vont bien, je fais des tests de chaque allocation et si au run-time, une exception intervient alors je vais les delete qui vont bien dans le bon ordre. Valgrind m'a bien aidé dans toute cette histoire :mrgreen:

---

Tu te compliques alors très certainement la vie.
Jette un oeil à la FAQ à la section RAII. En C++, valgrind peut vite s'avérer inutile dans la traque des fuites. Et je ne parle pas nécessairement de pointeur intelligent à comptage de référence. Mais juste de méthodologie en limitant le nombre de ressources brutes dont on peut être responsable à la fois à 1.

Un exemple de couplage fort:

Code:

---

1 2 3 4 5 6 7 8

class Foo {   friend class Dum;   private: // toutes les déclarations ici };

---

J'ai vu ça récemment (l'intégralité de la classe Dum, variables et fonctions, ne sont accéssibles que par la classe Foo).
En fin de compte - du point de vue du concept - cela revient à n'avoir qu'une seule classe divisée en deux (un peu à la manière du partial class en C#.

Citation:

---

Envoyé par r0d

Un exemple de couplage fort:

Code:

---

1 2 3 4 5 6 7 8

class Foo {   friend class Dum;   private: // toutes les déclarations ici };

---

J'ai vu ça récemment (l'intégralité de la classe Dum, variables et fonctions, ne sont accéssibles que par la classe Foo).
En fin de compte - du point de vue du concept - cela revient à n'avoir qu'une seule classe divisée en deux (un peu à la manière du partial class en C#.

---

En fait, c'est surtout l'inverse : l'intégralité de Foo n'est accessible qu'au travers de la classe Dum :D

Mais, effectivement, cela représente un couplage plutôt fort :D

Citation:

---

Envoyé par koala01

En fait, c'est surtout l'inverse : l'intégralité de Foo n'est accessible qu'au travers de la classe Dum :D

---

Oops oui :oops:
Au temps pour moi