Les cinq formes de couplage, de la plus acceptable à la pire

· Publié le · 1 min de lecture

Allez, histoire de vous changer un peu des posts IA, un peu de technique de software architecture.

Quelles sont pour vous les pires formes de couplage dans une codebase (l’ennemi numéro 1 à mon sens), du plus acceptable au moins acceptable ? Selon moi :

1. External coupling

Plusieurs modules dépendent du même système externe (DB, API…). On ne peut pas y couper totalement. Avec un système de port/adapter (architecture hexagonale), on peut se sauver la vie le jour où on veut migrer le système externe.

2. Common coupling

État global partagé et mutable (grosse config, gros contexte React fourre-tout…). Effets de bord, ordre d’exécution implicite, debugging pénible. À éviter et réduire au strict minimum (choses réellement globales et qui ne changent jamais ou quasiment jamais).

3. Control coupling

On passe des flags pour piloter le comportement interne d’un autre module. Les if s’accumulent. Préférer le polymorphisme, ou un système de composition si possible.

4. Stamp coupling

On passe un objet complet alors qu’on n’en utilise qu’une partie. Dépendance inutile à la structure. Il faut souvent préférer passer uniquement les données nécessaires.

5. Content coupling

Un module accède aux internals d’un autre. Le pire. À fuir. Quand ça arrive, c’est souvent par contrainte de temps pour faire mieux.

Vous en voyez d’autres ?

Le but n’étant pas de retirer 100 % du couplage (impossible), mais de le cantonner et de le maîtriser.

Sources