Come già detto, l’obiettivo di questo pattern è la progettazione delle dipendenze tra le varie classi in modo da minimizzare gli impatti alla variazione di una di esse: questo obiettivo può essere raggiunto tramite la riduzione dell’accoppiamento tra classi.

In realtà, è necessario effettuare una precisazione a questo principio: Low Coupling sostiene che sarebbe da evitare l’accoppiamento con classi ( metodi o oggetti) definiti ‘instabili’ , ossia classi la cui implementazione può variare con una certa frequenza, e quindi rendere instabile l’intero codice. 

Low Coupling riflette un obiettivo che viene spesso considerato dai designer come un parametro fondamentale di valutazione della qualità di progettazione del software: esso infatti incoraggia a scegliere una distribuzione di responsabilità che non faccia crescere il grado di accoppiamento nell’applicazione, in funzione dell’indipendenza e del riuso.

E’ da sottolineare che questo principio, comunque, non risulta essenziale se non si ha come obiettivo il riuso, anche se un forte disaccoppiamento fra classi comporta sicuramente dei deficit in termini di complessità del design e di efficienza del codice.
Si potrebbe infatti pensare alla situazione limite, in cui non esiste alcun accoppiamento fra classi: in teoria, questo potrebbe essere una condizione ottima per l’applicazione di questo principio, ma, d’altro canto, risulta irrealizzabile, e indesiderabile, in quanto non sussisterebbe la collaborazione tra gli oggetti, quindi ognuno di essi svolgerà il proprio compito in maniera del tutto isolata dal resto.

Una considerazione molto importante da sottolineare è la correlazione esistente tra il pattern Information Expert e il patter Low Coupling.

Information Expert, infatti, guida verso una scelta che sostiene Low Coupling, chiedendo di trovare l’oggetto che possiede la maggior parte delle informazioni richieste per la responsabilità in oggetto d’esame, e di assegnare quindi a quest’ultimo la responsabilità d svolgere quel determinato compito. Infatti, se si delega altrove questo compito, si aumenta l’accoppiamento complessivo, in quanto saranno presenti più oggetti o informazioni che devono essere condividi lontano dalla loro sorgente originale.

Supponiamo di dover implementare un client ftp. Una sbagliata progettazione sarebbe quella di includere la logica per la gestione delle connessioni client ftp all’interno dello strato che modella l’interfaccia utente. Questa situazione, infatti, comporterebbe numerosi problemi nel caso in cui si abbia la necessità di variare l’implementazione dell’interfaccia stessa, ad esempio fornire un’interfaccia testuale.

Low Coupling, insieme al pattern MVC ( Model-View-Controller) suggerisce invece di separare la logica di business dall’interfaccia grafica, quindi, di conseguenza, ridurre l’accoppiamento tra questi due strati, in modo da limitare al minimo gli interventi in caso di sostituzione, parziale o totale, di uno di essi. L’applicazione di Low Copuling in questo genere di situazioni è anche supportata dal fatto che l’interfaccia grafica, come anche gli strati di persistenza, viene  generalmente considerata come una componente instabile del sistema, che può subire spesso variazioni.

Come abbiamo visto, Low Copuling non è un vero e proprio pattern, ma piuttosto un principio da applicare per una corretta progettazione, soprattutto in casi in cui il riuso rappresenta una caratteristica importante per il sistema che si sta implementando.

Nel prossimo articolo analizzeremo un altro principio strettamente correlato a questo: High Coesion.