Inversione di dipendenza e disaccoppiamento

È molto difficile (anche se in un linguaggio che ha una riflessione non del tutto impossibile) creare un'applicazione disaccoppiata al 100%. Con la riflessione, possiamo usarlo per consentire all'utente di specificare classi concrete per ogni oggetto necessario nell'applicazione in fase di esecuzione (magari attraverso un file di configurazione), ottenendo così il disaccoppiamento completo a spese di una maggiore complessità.

Ma una domanda più importante da porsi è perché vorresti.

Cerchiamo di ridurre l'accoppiamento nella maggior parte del nostro codice perché l'accoppiamento rende le modifiche più difficili, causando una singola modifica che ha conseguenze per tutto il codice che è accoppiato al modulo che è stato modificato.

Ma se raggruppiamo tutto l'accoppiamento in un'unica posizione, questo problema viene mitigato. Una modifica al comportamento di un modulo può anche richiedere una modifica al codice che inizializza il modulo, ma poiché tutto questo codice viene mantenuto insieme non si propagano ulteriori cambiamenti da quel codice di inizializzazione, quindi non si verificano gli effetti negativi. Questo è abbastanza buono per quasi tutte le applicazioni.

Ordina. Non è possibile evitare del tutto l'accoppiamento. Il meglio che puoi fare è scambiare un tipo di accoppiamento per un genere generalmente più desiderabile. Invece di due oggetti concreti accoppiati tra loro, ciascuno di essi è accoppiato a un'interfaccia astratta.

Inoltre, devi dipendere da un'implementazione concreta al punto alcuni . Solo perché quelle dipendenze non vengono risolte finché il runtime non significa che non esistono. A volte il programmatore non si cura di quale implementazione concreta viene utilizzata, ma di solito hanno bisogno di un modo per specificarlo in qualche modo, il che significa un file di configurazione.

Quindi, mentre puoi avere un programma senza dipendenze concrete in fase di compilazione, di solito non ne vale la pena a meno che tu non abbia qualche necessità specifica di sostituire classi specifiche in fase di runtime.

L'accoppiamento stretto è cattivo. L'accoppiamento lento è quello che serve. E niente funziona in completo isolamento, quindi la dipendenza (per interfacciarsi) è inevitabile.

Le migliori pratiche sono la creazione di componenti disaccoppiati come descritto qui per evitare gli svantaggi di un'applicazione strettamente accoppiata come menzionato su questa pagina di Wikipedia . Prendi in considerazione anche le linee sottostanti in quanto hanno segnalato qui :

A module is closed if it has a well defined stable interface that all other modules must use and that limits the interaction and potential errors that can be introduced into one module by changes in another.

Grazie.

I'm wondering if someone might explain the last paragraph:

L'autore dice che avere "Dependency Inversion & ample Decoupling" da solo non è sufficiente.

Vuol dire che "collegare l'applicaton" implementando un metodo "principale" che costruisce tutte le classi è un'opzione tu usa i "moduli indipendenti"

Nel prossimo capitolo introduce come rendere più semplice il "cablaggio dell'applicativo tramite codice" introducendo "Iniezione delle dipendenze"

E più tardi introduce la molla-ioc che può fare la maggior parte delle operazioni di cablaggio per te.

Does this mean it is not possible to create a truly decoupled application?

No ma una molla di ioc come la può rendere molto più facile se hai compreso i principi che stanno dietro.