Discussion :

[Aspic]

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

[Klaim]

Le plus courant :

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

[themadmax]

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...

[Aspic]

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 ?

[nathieb]

Exemple JAVA

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Aspic]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Ca ne serait pas une erreur ?

[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

[Aspic]

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

[3DArchi]

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

• héritage (le plus fort) :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  class A : public B

• composition :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  class A
  {
     B b;
     std::unique_ptr<B> b2;
  };

• agrégation :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  class A
  {
     std::weak_ptr<B> b;
  };

• association:
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  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 :

  Sélectionner tout - Visualiser dans une fenêtre à part

  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.

[Aspic]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Merci

[Klaim]

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.

[therwald]

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.

[Aspic]

Parfait, merci pour la précision

[oodini]

• héritage (le plus fort) :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  class A : public B

• composition :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  class A
  {
     B b;
     std::unique_ptr<B> b2;
  };

• agrégation :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  class A
  {
     std::weak_ptr<B> b;
  };

• association:
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  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.

[Aspic]

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

+1
Parfaitement d'accord

[Luc Hermitte]

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 ?

[Aspic]

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

[koala01]

Salut,

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

[3DArchi]

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é.

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

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.

[nathieb]

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