Was ist der Unterschied zwischen loser und enger Kopplung im objektorientierten Paradigma?

Question

Kann jemand den genauen Unterschied zwischen loser Kopplung und enger Kopplung im objektorientierten Paradigma beschreiben?

Answer 1

Wenn zwei Objekte lose gekoppelt sind, können sie zwar interagieren, wissen aber nur sehr wenig über voneinander.

Lose gekoppelte Entwürfe ermöglichen uns den Aufbau flexibler OO-Systeme, die mit Veränderungen umgehen können.

Das Observer Design Pattern ist ein gutes Beispiel für die lose Kopplung von Klassen, Sie können es in Wikipedia .

Answer 2

Lose Kopplung bedeutet, dass der Grad der Abhängigkeit zwischen zwei Komponenten sehr gering ist.
Beispiel: GSM-SIM

Enge Kopplung bedeutet, dass der Grad der Abhängigkeit zwischen zwei Komponenten sehr hoch ist.
Beispiel: CDMA-Mobilfunk

Answer 3

Ein Auszug aus meinem Blogbeitrag auf der Kupplung:

Was ist Feste Kopplung :-

Gemäß der obigen Definition ist ein Tightly Coupled Object ein Objekt, das über andere Objekte Bescheid wissen muss und in der Regel in hohem Maße von den Schnittstellen der anderen Objekte abhängig ist.

Wenn wir ein Objekt in einer eng gekoppelten Anwendung ändern, erfordert dies oft Änderungen an einer Reihe anderer Objekte. In einer kleinen Anwendung ist das kein Problem, da wir die Änderung leicht erkennen können. Bei großen Anwendungen sind diese Abhängigkeiten jedoch nicht immer allen Nutzern oder anderen Entwicklern bekannt, oder es gibt viele Möglichkeiten für zukünftige Änderungen.

Nehmen wir einen Einkaufswagen-Democode, um die enge Kopplung zu verstehen:

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);
        }
    }
}

Probleme mit dem obigen Beispiel

Die enge Kopplung bringt einige Schwierigkeiten mit sich.

Hier, OrderTotal() Methoden ist es, uns den kompletten Betrag für die aktuellen Artikel des Wagens zu geben. Wenn wir die Rabatt-Funktionen in diesem Warenkorb-System hinzufügen möchten. Es ist sehr schwer, in obigem Code zu tun, weil wir Änderungen an jeder Klasse vornehmen müssen, da es sehr eng gekoppelt ist.

Answer 4

Es gibt hier viele schöne Antworten mit Analogien, aber ein Arbeitskollege hat mir ein Beispiel gegeben, das mir besser gefallen hat als alle anderen hier genannten... Augen und Brillen!

Feste Kopplung

Eine enge Kopplung würde die Augen betreffen. Wenn ich meine Sehkraft wiederherstellen möchte, ist eine Augentransplantation sehr teuer und birgt ein gewisses Risiko. Aber was wäre, wenn der Designer (also die menschliche Rasse) einen besseren Weg finden würde? Fügen Sie eine Funktion hinzu, die lose an den Körper gekoppelt ist, so dass sie leicht verändert werden kann! (ja eine Brille)

Lose Kopplung

Ich kann meine Brille problemlos austauschen, ohne dass meine Sehkraft darunter leidet. Ich kann die Brille abnehmen, und meine Sehkraft bleibt wie vorher (nicht besser oder schlechter). Die Verwendung verschiedener Brillen verändert die Art und Weise, wie wir die Welt durch unsere Augen sehen, mit geringem Risiko und einfacher Instandhaltung.

Zusammenfassung

Wenn Sie also das nächste Mal jemand fragt: "Wen interessiert es, ob mein Code eng gekoppelt ist?" Die Antwort ist eine Frage des Änderungsaufwands, des Wartungsaufwands und des Änderungsrisikos.

Wie wird dies nun in C# gemacht? Interfaces und Dependency Injection!

EDITAR

Dies ist auch ein gutes Beispiel für das Decorator-Muster, bei dem die Augen die Klasse sind, die wir dekorieren, indem wir die Anforderungen an die Schnittstelle erfüllen, aber unterschiedliche Funktionen bieten (z. B. Sonnenbrillen, Lesebrillen, Lupen für Juweliere usw.).

Answer 5

So wie ich es verstehe, bietet eine eng gekoppelte Architektur im Vergleich zu einer lose gekoppelten Architektur nicht viel Flexibilität für Änderungen.

Aber bei lose gekoppelten Architekturen haben Nachrichtenformate oder Betriebsplattformen oder die Überarbeitung der Geschäftslogik keine Auswirkungen auf die andere Seite. Wenn das System für eine Umstellung heruntergefahren wird, kann die andere Seite natürlich eine Zeit lang nicht auf den Dienst zugreifen, aber ansonsten kann die unveränderte Seite den Nachrichtenaustausch wie vor der Umstellung wieder aufnehmen.