Comprendre le couplage lâche / serré dans le «monde réel»

Je ne dirai pas ce que "communauté" parce que je veux une explication non biaisée, mais disons que vous construisez un module réutilisable et que ce module nécessite 3+ modules dépendants et la suppression de 1 d'entre eux provoque une erreur de rupture non seulement dans votre application en tant que ensemble qui utilise ce module, mais le module lui-même.

D'après ma compréhension (ce qui doit être faux), un système modulaire faiblement couplé ne se cassera pas en retirant simplement un module. L'application devrait toujours fonctionner mais sans cette "fonctionnalité" / module et le module lui-même ne devrait pas faire en sorte que tout ne s'exécute pas simplement parce qu'un module dépendant n'existe pas.

Est-ce mal? Si oui, si les modules sont toujours dépendants au point que tout ne fonctionne pas, quelle est la différence entre un couplage serré / desserré?

Pas tout à fait --- le retrait du module pourrait bien casser le système. L'idée derrière les systèmes à couplage lâche est que l'échange dans un module complètement différent fonctionnera très bien tant que le nouveau module est conforme aux mêmes exigences d'interface que l'ancien. S'il était étroitement couplé, le code environnant ferait des présomptions sur les internes et commencerait à échouer si un nouveau module était introduit.

Le couplage lâche est essentiellement la dépendance indirecte entre les modules sur la façon dont ils peuvent évoluer.

Généralement, lorsqu'il existe un système étroitement couplé, différents modules / objets ont des comportements très spécifiques qui supposent ce comportement des objets périphériques. Ces objets sont liés / couplés à d'autres comportements de modules et ils ne peuvent pas être réutilisés isolément ou dans tout autre contexte.

De tels modules, même s'ils sont responsables de fonctionnalités individuelles, ne peuvent pas évoluer indépendamment ou ne peuvent pas évoluer

Un exemple:

Disons que vous avez 3 objets Shape(un objet modèle) et Canvas(un élément d'interface utilisateur). Maintenant

Supposons qu'une méthode shape.draw(Canvas)dessine un objet sur le plan fourni par le plan du canevas.

Maintenant, parfois les fenêtres sont partiellement couvertes et redimensionnées. Dans de tels cas, la méthode ci-dessus pourrait simplement faire quelque chose comme ça.

shape::draw(Canvas) {
   Rect.WindowLeft = Canvas.GetWindowRect.getLeftOffset(); 
   Rect.LeftPixel = Canvas.GetWindowRect.pixels() + Rect.WindowLeft; 
   ....  // like this get all co-ordinates. 

   draw_instance(Rect);  // This will draw the actual shape. 
}

Fondamentalement, ici, la fonction de dessin prend le rectangle où les choses doivent être dessinées. C'est un code facile à comprendre (les gens pourraient appeler cela simple ). Cependant, il s'agit d'un code extrêmement couplé.

Imaginez la situation:

• Que se passe-t-il si le mécanisme de la toile pour tenir les fenêtres n'est plus un rectangle?
• que se passe-t-il s'il existe des décalages supplémentaires que Canvas conserve et qui sont privés ?
• Et si une autre application veut la même forme mais n'a plus de fenêtre GUI (par exemple, elle crée des images et enregistre dans des fichiers).

La cause profonde du problème est que l'objet shape sait et donc étroitement couplé avec Canvas.

Ce qui est souhaitable qu'un ensemble de pixels soit donné pour façonner où il écrit; la shapeconnaissance ne doit pas avoir (même implicite) sur l' endroit où sont réellement écrites les pixels.

Cela dépend, même de ce que vous spécifiez comme module. Certaines parties du système doivent être étroitement couplées (par exemple, vos entités doivent être réutilisées sur l'ensemble de l'application), mais certains systèmes doivent être lâches, soit avec des séparations d'interface, soit si nous parlons de ne pas interrompre l'application si vous supprimez le module , alors ce module doit être câblé de manière dynamique, peut-être via un conteneur IoC ou quelque chose.

En outre, un couplage étroit signifie qu'une partie dépend de la mise en œuvre d'un module spécifique , et non de la définition du module ou de quelque chose.