"Dependency Inversion" e "Design to Interfaces" sono gli stessi principi?

Question

Il "principio di inversione delle dipendenze" (DIP) e il "principio di progettazione per le interfacce" esprimono lo stesso principio? In caso contrario, quale sarebbe la differenza?

EDIT

Per chiarire e circoscrivere il contesto un po ': da interfaccia intendo un'interfaccia di programmazione, come Java interface o di una pura classe base astratta in C++. Nessun altro "contratto" è coinvolto.

Answer 1

"design by contract" e "dependency injection" sono strettamente correlati, ma hanno diversi livelli di astrazione. "design by contract" è un principio di progettazione molto generale, che può essere supportato da varie tecniche; In una lingua che ha un sistema di classe simile a Java, una tecnica è quella di utilizzare le interfacce per evitare dipendenze di classe concrete. "Iniezione di dipendenza" è un'altra tecnica, che spesso si basa sull'esistenza di interfacce per funzionare (ma non sempre è necessario farlo: dipende dalla lingua). Direi che "l'iniezione di dipendenza" supporta il principio della "progettazione per contratto".

Answer 2

La progettazione in interfacce (come variante di design by contract) supporta l'inversione di dipendenza. Entrambi riducono l'accoppiamento. Tuttavia:

• design nei interfacce e DBC dice nulla su come gli oggetti vengono creati (per esempio DIP, abstract factories, factory methods).
• Inversione di dipendenza (dependency injection) generalmente si basa sulle interfacce, ma si concentra sul ciclo di vita dell'oggetto anziché sulla progettazione della classe. È possibile utilizzare DIP con classi di base astratte, se lo si desidera, quindi non si è veramente impegnati a interfacce pure.

Gli approcci tendono a completarsi a vicenda.

Answer 3

Volevo solo inserire e citare Derek Greer su another question very similar to this one, poiché risponde a questa domanda piacevolmente, a mio parere.

"Che Inversion Principle dipendenza non si riferisce a è la semplice pratica di astrazione dipendenze attraverso l'uso di interfacce (ad esempio MyService → [ILogger ⇐ Logger])."

Mentre questo disaccoppia un componente dallo specifico dettaglio attuazione della dipendenza, essa non invertire il rapporto tra il consumatore e dipendenza (ad es [MyService → IMyServiceLogger] ⇐ Logger)."

Answer 4

Dipendenza inversione è garantire i moduli di livello più alto non dipendono da moduli di livello inferiore, quindi la logica dell'applicazione non dipende dal modello di business o dalla logica aziendale.Esiste una chiara separazione dei problemi

Il principio afferma che l'applicazione definisce e possiede un'interfaccia del livello aziendale deve implementare il tuo livello aziendale dipende dall'interfaccia definita dell'applicazione. Quindi le dipendenze sono invertite.

Espandendo questo aspetto, se ora disponi di tre applicazioni, ognuna con le proprie interfacce implementate dal livello aziendale, il tuo livello aziendale può cambiare e fintanto che implementano le interfacce come devono, allora le tue applicazioni non ne sono più saggi.

Un buon java esempio di questo principio e come un tale progetto sarebbe stato strutturato può essere trovato qui, sul mio sito web: http://www.jeenisoftware.com/maven-dip-principle-example/

inversione di dipendenza non è tanto sul design per interfacciarsi, anche se questo è ciò che sta accadendo , si tratta più dell'implementazione di un servizio. In altre parole una sorta di modello di progettazione orientata al servizio.