Lose / enge Kopplung in der „realen Welt“ verstehen

Ich werde nicht sagen, was "Community" ist, weil ich eine nicht voreingenommene Erklärung möchte, aber nehmen wir an, Sie erstellen ein wiederverwendbares Modul und dieses Modul erfordert mehr als 3 abhängige Module. Das Entfernen von einem davon führt nicht nur in Ihrer App als zu einem fehlerhaften Fehler Ganzes, das dieses Modul verwendet, aber das Modul selbst.

Nach meinem Verständnis (was falsch sein muss) wird ein lose gekoppeltes modulares System nicht durch einfaches Entfernen eines Moduls kaputt gehen. Die App sollte weiterhin ausgeführt werden, jedoch ohne diese "Funktion" / dieses Modul, und das Modul selbst sollte nicht dazu führen, dass nicht alles ausgeführt wird, nur weil kein abhängiges Modul vorhanden ist.

Ist das falsch? Wenn ja, wenn Module immer noch davon abhängig sind, dass alles nicht funktioniert, was ist der Unterschied zwischen dichter / loser Kupplung?

Nicht ganz --- Das Entfernen des Moduls könnte das System beschädigen. Die Idee hinter lose gekoppelten Systemen ist, dass das Austauschen in ein völlig anderes Modul einwandfrei funktioniert, solange das neue Modul den gleichen Schnittstellenanforderungen wie das alte entspricht. Wenn es eng gekoppelt wäre, würde der umgebende Code Vermutungen über die Interna anstellen und würde fehlschlagen, wenn ein neues Modul eingeführt würde.

Lose Kopplung ist im Wesentlichen die indirekte Abhängigkeit zwischen Modulen davon, wie sie sich entwickeln können.

Im Allgemeinen weisen verschiedene Module / Objekte bei eng gekoppelten Systemen ein sehr spezifisches Verhalten auf, das dieses Verhalten der peripheren Objekte voraussetzt. Solche Objekte sind mit dem Verhalten anderer Module verknüpft / gekoppelt und können nicht isoliert oder in einem anderen Kontext wiederverwendet werden.

Solche Module können sich, obwohl sie für die individuelle Funktionalität verantwortlich sind, nicht unabhängig oder nicht weiterentwickeln

Ein Beispiel:

Angenommen, Sie haben 3 Objekte Shape(ein Modellobjekt) und Canvas(ein UI-Element). Jetzt

Angenommen, eine Methode shape.draw(Canvas)zeichnet ein Objekt auf der Ebene, die von der Ebene der Leinwand geliefert wird.

Jetzt sind Fenster manchmal teilweise abgedeckt und werden in der Größe geändert. In solchen Fällen kann die obige Methode genau so etwas tun.

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

Grundsätzlich nimmt hier die Zeichenfunktion das Rechteck auf, in dem Dinge gezeichnet werden müssen. Dies ist ein leicht verständlicher Code (die Leute könnten diesen einfachen Code nennen ). Dies ist jedoch ein extrem gekoppelter Code.

Stellen Sie sich die Situation vor:

• Was ist, wenn der Mechanismus der Leinwand zum Halten von Fenstern kein Rechteck mehr ist?
• Was ist, wenn Canvas zusätzliche Offsets behält, die privat sind ?
• Was ist, wenn eine andere Anwendung dieselbe Form haben möchte, aber kein GUI-Fenster mehr hat (z. B. Bilder erstellen und in Dateien speichern)?

Die Hauptursache des Problems ist, dass das Objekt es shape kennt und daher eng mit ihm verbunden ist Canvas.

Was ist wünschenswert, dass ein Pixelsatz gegeben wird, um zu formen, wo er schreibt; Sie shapesollten nicht (auch nicht implizit) wissen, wo die Pixel tatsächlich geschrieben sind.

Dies hängt auch davon ab, was Sie als Modul angeben. Einige Teile des Systems sollten eng miteinander verbunden sein (z. B. sollten Ihre Entitäten in der gesamten App wiederverwendet werden), aber einige Systeme sollten lose sein, entweder mit Schnittstellentrennungen oder wenn wir davon sprechen, die Anwendung nicht zu beschädigen, wenn Sie das Modul entfernen Dann muss das Modul irgendwie dynamisch verkabelt werden, vielleicht über einen IoC-Container oder so.

Eine enge Kopplung bedeutet auch, dass ein Teil von der spezifischen Modulimplementierung abhängt , nicht von der Definition des Moduls oder etwas anderem.