Quelle est la différence entre un couplage lâche et un couplage étroit dans le paradigme orienté objet?
Peut-on décrire la différence exacte entre couplage lâche et couplage étroit dans le paradigme orienté objet?
Le couplage étroit se produit lorsqu'un groupe de classes est fortement dépendant les unes des autres.
Ce scénario se produit lorsqu'une classe assume trop de responsabilités ou lorsqu'une préoccupation concerne plusieurs classes plutôt que d'avoir sa propre classe.
Le couplage lâche est obtenu grâce à une conception qui favorise la responsabilité unique et la séparation des préoccupations.
Une classe faiblement couplée peut être consommée et testée indépendamment des autres classes (concrètes).
Les interfaces sont un outil puissant à utiliser pour le découplage. Les classes peuvent communiquer via des interfaces plutôt que d'autres classes concrètes, et n'importe quelle classe peut se trouver à l'autre extrémité de cette communication en mettant simplement en œuvre l'interface.
Exemple de couplage serré:
class CustomerRepository
{
private readonly Database database;
public CustomerRepository(Database database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
class Database
{
public void AddRow(string Table, string Value)
{
}
}
Exemple de couplage lâche:
class CustomerRepository
{
private readonly IDatabase database;
public CustomerRepository(IDatabase database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
interface IDatabase
{
void AddRow(string Table, string Value);
}
class Database : IDatabase
{
public void AddRow(string Table, string Value)
{
}
}
Un autre exemple ici .
Explication simple sans code
Exemple de résumé:
Le chapeau est "vaguement couplé" au corps. Cela signifie que vous pouvez facilement enlever le chapeau sans apporter de modifications à la personne ou au corps. Lorsque vous pouvez faire cela, vous obtenez un "couplage lâche". Voir ci-dessous pour plus de détails.
Couplage serré (exemple détaillé)
Pense à ta peau. C'est collé à ton corps. Il va comme un gant. Mais que faire si vous voulez changer la couleur de votre peau de blanc à noir? Pouvez-vous imaginer à quel point il serait douloureux de décoller votre peau, de la teindre puis de la coller à nouveau, etc.? Changer de peau est difficile car il est étroitement couplé à votre corps. Vous ne pouvez pas faire de changements facilement. Pour rendre cela possible, il vous faudrait repenser fondamentalement un être humain.
- Point clé n ° 1 _ En d'autres termes, si vous voulez changer de skin, vous DEVEZ aussi changer la forme de votre corps}, car les deux sont réunis - ils sont étroitement couplés.
Dieu n'était pas un bon programmeur orienté objet.
Couplage lâche (exemple détaillé)
Maintenant, pensez à vous habiller le matin. Tu n'aimes pas le bleu? Pas de problème: vous pouvez mettre une chemise rouge à la place. Vous pouvez le faire facilement et sans effort, car la chemise n’est pas vraiment reliée à votre corps de la même façon que votre peau. _ {La chemise ne sait ni ne se soucie de son corps}. En d'autres termes, vous pouvez changer de vêtements sans vraiment changer de corps.
- C'est le point clé n ° 2. Si vous changez de chemise, vous n'êtes pas obligé de changer de corps} - lorsque vous pouvez le faire, vous avez alors un couplage lâche. Lorsque vous ne pouvez pas faire cela, alors vous avez un couplage étroit.
C'est le concept de base en un mot.
Pourquoi tout cela est-il important?
C'est important parce que les logiciels changent tout le temps. De manière générale, vous souhaitez pouvoir modifier facilement votre code.
Exemples pratiques de couplage en informatique
- Si quelqu'un veut leur sortie dans un fichier CSV plutôt que JSON, etc., ou si vous voulez passer de MySQL à PostGreSQL, vous devriez être capable de faire ces changements extrêmement facilement dans votre code, sans avoir à réécrire toute la classe, etc. En d'autres termes, vous ne souhaitez pas associer étroitement votre application à une implémentation de base de données spécifique (par exemple, Mysql) ou à une sortie particulière (par exemple, des fichiers CSV). Parce que, comme c'est inévitable dans les logiciels, des changements vont se produire. Quand ils arrivent, c'est beaucoup plus facile si vos parties de votre code sont faiblement couplées.
Autre exemple: L’analogie du couplage entre voiture et pièces de rechange
- Si quelqu'un veut sa voiture dans noir , vous ne devriez pas avoir à refaire la conception de la voiture entière pour le faire. Une voiture et ses pièces de rechange seraient un exemple parfait d'architecture à couplage lâche (selon les commentaires de @ mnmopazem). Si vous souhaitez remplacer votre moteur par un meilleur, vous devriez pouvoir le retirer sans trop d'effort et l'échanger contre un meilleur. Si votre voiture fonctionne uniquement avec les moteurs Rolls Royce 1234 et aucun autre moteur, votre voiture sera alors couplée étroitement à ce moteur (Rolls Royce 1234). Il serait préférable que vous modifiiez la conception de votre voiture pour qu'elle fonctionne avec le moteur n'importe quel, de sorte qu'elle soit un peu plus faiblement couplée à ses composants. Mieux encore, votre voiture pourrait fonctionner sans avoir besoin d'un moteur! Un certain couplage va se produire, mais vous devriez travailler pour le minimiser autant que vous le pouvez. Pourquoi? Parce que lorsque les exigences changent, nous devrions toujours être en mesure de fournir des logiciels de bonne qualité très rapidement et nous sommes aidés dans cet objectif par un couplage lâche.
Résumé
En bref, un couplage lâche facilite le changement de code. Les réponses ci-dessus fournissent un code qui mérite d’être lu à ce stade.
Dans la conception orientée objet, la quantité de couplage fait référence à la mesure dans laquelle la conception d'une classe dépend de la conception d'une autre classe. En d’autres termes, à quelle fréquence les changements dans la classe A liés à la force changent-ils dans la classe B? Un couplage étroit signifie que les deux classes changent souvent ensemble, un couplage lâche signifie qu'elles sont généralement indépendantes. En général, un couplage lâche est recommandé car il est plus facile à tester et à entretenir.
Vous pouvez trouver cet article de Martin Fowler (PDF) utile.
En général, Tight Coupling est mauvais dans la plupart des cas, car il réduit la flexibilité et la possibilité de réutilisation du code, il rend les modifications beaucoup plus difficiles, empêche la testabilité, etc.
Tightly Coupled Object est un objet qui a besoin de connaître un peu l’un de l’autre et qui dépend généralement beaucoup de ses interfaces. Changer un objet dans une application étroitement couplée nécessite souvent des modifications sur un certain nombre d'autres objets. Dans une petite application, nous pouvons facilement identifier les modifications et il y a moins de chance de rien rater. Mais dans les grandes applications, tous les programmeurs ne connaissent pas toujours ces interdépendances, sinon les changements risquent de manquer. Mais chaque ensemble d'objets faiblement couplés ne dépend pas des autres.
En bref, nous pouvons dire que le couplage faible est un objectif de conception qui vise à réduire les interdépendances entre les composants d’un système dans le but de réduire le risque que les modifications d’un composant nécessitent des modifications dans tout autre composant. Le couplage lâche est un concept beaucoup plus générique destiné à accroître la flexibilité d'un système, à le rendre plus facile à gérer et à rendre l'ensemble du cadre plus «stable».
Le couplage fait référence au degré de connaissance directe qu'un élément possède d'un autre. on peut dire par exemple: A et B, seul B change de comportement uniquement lorsque A change de comportement. Un système faiblement couplé peut être facilement décomposé en éléments définissables.
Lorsque deux objets sont couplés de manière lâche, ils peuvent interagir mais ont très peu de connaissances les uns des autres.
Les conceptions faiblement couplées nous permettent de construire des systèmes OO flexibles capables de gérer les changements.
Le modèle de conception Observer est un bon exemple de création de classes faiblement couplées. Vous pouvez le consulter dans Wikipedia .
Si j'ai bien compris, cette architecture à couplage étroit ne confère pas beaucoup de flexibilité pour le changement par rapport à une architecture à couplage lâche.
Toutefois, dans le cas d'architectures faiblement couplées, de formats de message ou de plates-formes d'exploitation ou d'une refonte de la logique métier, cela n'a pas d'incidence sur l'autre extrémité. Si le système est mis hors service pour une refonte, il est bien évident que l’autre extrémité ne pourra pas accéder au service pendant un certain temps, mais à part cela, la fin inchangée peut reprendre l’échange de messages comme elle l’était avant la refonte.
Un extrait de mon blog post on couplage:
Qu'est-ce que Couplage serré: -
Comme définition ci-dessus, un objet à couplage étroit est un objet qui a besoin de connaître d’autres objets et qui dépendent généralement beaucoup des interfaces de chacun.
Lorsque nous modifions un objet dans une application étroitement couplée, il est souvent nécessaire de modifier plusieurs autres objets. Il n'y a pas de problème dans une petite application, nous pouvons facilement identifier le changement. Toutefois, dans le cas d'applications volumineuses, ces interdépendances ne sont pas toujours connues de tous les consommateurs ou de tous les développeurs, ou il existe de nombreuses possibilités de modifications futures.
Prenons un code de démonstration de caddie pour comprendre le couplage étroit:
namespace DNSLooseCoupling
{
public class ShoppingCart
{
public float Price;
public int Quantity;
public float GetRowItemTotal()
{
return Price * Quantity;
}
}
public class ShoppingCartContents
{
public ShoppingCart[] items;
public float GetCartItemsTotal()
{
float cartTotal = 0;
foreach (ShoppingCart item in items)
{
cartTotal += item.GetRowItemTotal();
}
return cartTotal;
}
}
public class Order
{
private ShoppingCartContents cart;
private float salesTax;
public Order(ShoppingCartContents cart, float salesTax)
{
this.cart = cart;
this.salesTax = salesTax;
}
public float OrderTotal()
{
return cart.GetCartItemsTotal() * (2.0f + salesTax);
}
}
}
Problèmes avec l'exemple ci-dessus
Le couplage serré crée certaines difficultés.
Ici, les méthodes OrderTotal() nous donnent le montant complet pour les articles courants des paniers. Si nous voulons ajouter les fonctionnalités de réduction dans ce système de panier. C'est très difficile à faire dans le code ci-dessus car nous devons apporter des modifications à chaque classe car il est très étroitement lié.
Certains outils fournissent une injection de dépendance via leur bibliothèque, par exemple en .net nous avons ninject Library .
Si vous allez plus loin en Java, alors spring fournit ces fonctionnalités.
Des objets faiblement couplés peuvent être créés en introduisant des interfaces dans votre code, ce que font ces sources.
Dites dans votre code que vous écrivez
Myclass m = new Myclass();
maintenant, cette déclaration dans votre méthode indique que vous êtes dépendant de myclass, cela s'appelle un couplage étroit. Maintenant, vous fournissez une injection de constructeur, ou une injection de propriété et un objet d'instanciation, puis il sera couplé de manière lâche.
Un couplage faible signifie que le degré de dépendance entre deux composants est très faible.
Exemple: GSM SIM
Un couplage étroit signifie que le degré de dépendance entre deux composants est très élevé.
Exemple: CDMA Mobile
Le couplage lâche répond aux anciennes dépendances codées en dur et aux problèmes connexes, tels que la recompilation fréquente lorsque quelque chose change et la réutilisation du code. Il insiste sur la mise en œuvre de la logique de travail dans les composants et l’évitement du code de câblage spécifique à la solution.
Loose Coupling = IoC Voir this pour une explication plus facile.
Couplage étroit signifie qu'une classe dépend d'une autre classe.
Couplage lâche signifie qu'une classe dépend de l'interface plutôt que de la classe.
Dans couplage étroit , il existe des dépendances codées en dur déclarées dans les méthodes.
Dans couplage lâche , nous devons passer la dépendance en externe au moment de l’exécution au lieu de coder en dur. (Les systèmes à couple lâche utilisent une interface pour réduire la dépendance avec la classe.)
Par exemple, nous avons un système qui peut envoyer une sortie de deux manières ou plus, comme une sortie JSON, une sortie CSV, etc.
Serré couplé
public interface OutputGenerator {
public void generateOutput();
}
public class CSVOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("CSV Output Generator");
}
}
public class JSONOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("JSON Output Generator");
}
}
// In Other Code, we write Output Generator like...
public class Class1 {
public void generateOutput() {
// Here Output will be in CSV-Format, because of hard-coded code.
// This method tightly coupled with CSVOutputGenerator class, if we want another Output, we must change this method.
// Any method, that calls Class1's generateOutput will return CSVOutput, because Class1 is tight couple with CSVOutputGenerator.
OutputGenerator outputGenerator = new CSVOutputGenerator();
output.generateOutput();
}
}
Dans l'exemple ci-dessus, si nous voulons modifier la sortie en JSON, nous devons rechercher et modifier tout le code, car Class1 est étroitement associé à la classe CSVOutputGenerator.
Loose Coupled
public interface OutputGenerator {
public void generateOutput();
}
public class CSVOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("CSV Output Generator");
}
}
public class JSONOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("JSON Output Generator");
}
}
// In Other Code, we write Output Generator like...
public class Class1 {
public void generateOutput(OutputGenerator outputGenerator) {
// if you want to write JSON, pass object of JSONOutputGenerator (Dependency will be passed externally to this method)
// if you want to write CSV, pass object of CSVOutputGenerator (Dependency will be passed externally to this method)
// Due to loose couple with class, we don't need to change code of Class1, because Class1 is loose coupled with CSVOutputGenerator or JSONOutputGenerator class
// Any method, that calls Class1's generateOutput will desired output, because Class1 does not tight couple with CSVOutputGenerator or JSONOutputGenerator class
OutputGenerator outputGenerator = outputGenerator;
output.generateOutput();
}
}
Le couplage en vrac est le processus qui consiste à donner indirectement la dépendance dont votre classe a besoin sans fournir toutes les informations de la dépendance (c'est-à-dire dans l'interface de départ) au cas où un couplage étroit donnerait directement la dépendance, ce qui n'est pas un bon moyen de codage.
Si la création/l'existence d'un objet dépend d'un autre objet qui ne peut pas être personnalisé, son couplage étroit. Et, si la dépendance peut être adaptée, son couplage lâche. Prenons un exemple en Java:
class Car {
private Engine engine = new Engine( "X_COMPANY" ); // this car is being created with "X_COMPANY" engine
// Other parts
public Car() {
// implemenation
}
}
Le client de la classe Car peut en créer un avec le moteur ONLY "X_COMPANY".
Envisagez de rompre ce couplage avec la possibilité de changer cela:
class Car {
private Engine engine;
// Other members
public Car( Engine engine ) { // this car can be created with any Engine type
this.engine = engine;
}
}
Maintenant, une Car ne dépend pas d'un moteur de "X_COMPANY" car elle peut être créée avec des types.
Une note spécifique à Java: utiliser des interfaces Java uniquement pour dissocier des données n’est pas une bonne approche. En Java, une interface a pour but - d’agir en tant que contrat fournissant intrinsèquement un comportement/avantage de découplage.
Le commentaire de Bill Rosmus en réponse acceptée a une bonne explication.
Il y a beaucoup de bonnes réponses ici en utilisant des analogies mais un ami au travail m'a donné un exemple que j'ai aimé plus que tous ceux mentionnés ici ... Eyes and Glasses!
Couplage serré
Couplage serré serait les yeux. Si je veux améliorer ma vision, il me coûte très cher de subir une greffe d'un œil et comporte pas mal de risques. Mais que se passe-t-il si le concepteur (étant la race humaine) a trouvé un meilleur moyen. Ajoutez une fonctionnalité qui est couplée de manière lâche au corps afin de pouvoir la changer facilement! (oui .. lunettes)
Couplage lâche
Je peux facilement remplacer mes lunettes sans briser ma vision sous-jacente. Je peux enlever mes lunettes et ma vision sera comme avant (pas mieux ou pire). L'utilisation de différentes paires de lunettes modifie la façon dont nous voyons le monde à travers nos yeux avec peu de risque et une facilité d'entretien.
Résumé
Alors, la prochaine fois, quelqu'un vous demandera: "Peu importe si mon code est étroitement lié?" La réponse est tout au sujet des efforts de changement, des efforts de maintien et des risques de changement.
Alors, comment cela se fait-il en C #? Interfaces et injection de dépendance!
MODIFIER
C’est aussi un bon exemple du motif Decorator, où les yeux sont la classe que nous décorons en répondant aux exigences d’interface mais en offrant des fonctionnalités différentes (par exemple, lunettes de soleil, lunettes de lecture, loupes pour bijoutiers, etc.).