Comprensione dell'accoppiamento allentato / stretto nel "mondo reale"

Non dico quale "comunità" perché voglio una spiegazione non distorta, ma supponiamo che tu stia costruendo un modulo riutilizzabile e quel modulo richiede 3+ moduli dipendenti e la rimozione di uno di essi provoca un errore di rottura non solo nella tua app come intero che utilizza questo modulo, ma il modulo stesso.

Secondo la mia comprensione (che deve essere errata), un sistema modulare accoppiato liberamente non si romperà semplicemente rimuovendo un modulo. L'app dovrebbe comunque funzionare ma senza quella "funzionalità" / modulo e il modulo stesso non dovrebbe far funzionare tutto semplicemente perché non esiste un modulo dipendente.

È sbagliato? In tal caso, se i moduli dipendono ancora dal punto in cui tutto non funziona, qual è la differenza tra accoppiamento stretto / lento?

Non proprio --- la rimozione del modulo potrebbe danneggiare il sistema. L'idea alla base dei sistemi vagamente accoppiati è che lo scambio in un modulo completamente diverso funzionerà perfettamente fino a quando il nuovo modulo sarà conforme agli stessi requisiti di interfaccia di quello precedente. Se fosse strettamente accoppiato, il codice circostante farebbe presunzioni sugli interni e inizierebbe a fallire se fosse introdotto un nuovo modulo.

L'accoppiamento libero è essenzialmente la dipendenza indiretta tra il modulo su come possono evolversi.

Generalmente, quando esiste un sistema strettamente accoppiato, diversi moduli / oggetti hanno comportamenti molto specifici che assumono quel comportamento degli oggetti periferici. Tali oggetti sono collegati / accoppiati a comportamenti di altri moduli e non possono essere riutilizzati in modo isolato o in qualsiasi altro contesto.

Tali moduli anche se responsabili della funzionalità individuale non possono evolversi indipendentemente o non possono evolversi

Un esempio:

Supponiamo che tu abbia 3 oggetti Shape(un oggetto modello) e Canvas(un elemento UI). Adesso

Supponiamo che un metodo shape.draw(Canvas)disegnerà un oggetto sul piano che viene fornito dal piano della tela.

Ora, a volte le finestre sono parzialmente coperte e ridimensionate. In questi casi, il metodo sopra potrebbe fare qualcosa del genere.

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

Fondamentalmente, qui la funzione di disegno raccoglie il rettangolo in cui le cose devono essere disegnate. Questo è un codice di facile comprensione (la gente potrebbe chiamare questo semplice ). Tuttavia, questo è un codice estremamente accoppiato.

Immagina la situazione:

• Che cosa succede se il meccanismo della tela di contenere finestre non è più un rettangolo?
• cosa succede se ci sono ulteriori offset che Canvas mantiene che è privato ?
• Che cosa succede se un'altra applicazione vuole la stessa forma ma non ha più una finestra della GUI (ad esempio, sta creando immagini e salvando nei file).

La causa principale del problema è che oggetto shape conosce e quindi strettamente accoppiati con Canvas.

Ciò che è desiderabile che venga dato un set di pixel per modellare dove scrive; il shapenon dovrebbe avere conoscenza (anche implicito) su cui i pixel sono effettivamente scritti.

Dipende, anche da ciò che si specifica come modulo. Alcune parti del sistema dovrebbero essere strettamente accoppiate (ad esempio, le entità dovrebbero essere riutilizzate nell'intera app), ma alcuni sistemi dovrebbero essere allentati, con separazioni dell'interfaccia o se stiamo parlando di non interrompere l'applicazione se si rimuove il modulo , quindi quel modulo deve essere cablato in qualche modo in modo dinamico, magari attraverso il contenitore IoC o qualcosa del genere.

Inoltre, l'accoppiamento stretto significa che una parte dipende dall'implementazione specifica del modulo, non dalla definizione del modulo o qualcosa del genere.