Programmazione pratica secondo il principio di inversione delle dipendenze

1

Ciò che il Principio di Inversione di dipendenza implica in pratica è che in un sistema, i componenti di alto livello dovrebbero dipendere dalle astrazioni dei componenti di basso livello (invece che dai componenti di basso livello direttamente), e le componenti di basso livello dovrebbero essere definite in termini di queste astrazioni.

Il punto chiave della mia domanda è che i componenti di basso livello sono definiti in termini di astrazioni, che sono definite in termini di componenti di alto livello . Significato: le componenti di alto livello 'definiscono l'astrazione' in termini di ciò che sarebbe conveniente per loro, e le componenti di basso livello devono essere definite secondo quell'astrazione (di solito un'interfaccia).

Quindi se il componente di alto livello è un Car , e il componente di basso livello è Engine , e viene definita un'interfaccia IEngine - sarà definita in base alle esigenze del Car , e Engine dovrà soddisfare queste esigenze. Quindi, se è conveniente che Car sia in grado di avviare semplicemente il motore, IEngine conterrà un metodo start() e Engine dovrebbe implementarlo.

La mia domanda è:

Quando si inizia la programmazione su un progetto progettato secondo il principio di inversione delle dipendenze - sono i componenti di alto livello solitamente implementati prima di quelli di basso livello, vale a dire. Sviluppo "dall'alto verso il basso"?

Poiché il principio implica che i componenti di basso livello siano progettati in base a ciò che è conveniente per i componenti di alto livello, è logico iniziare prima a programmare i componenti di alto livello e solo successivamente definire l'interfaccia ILowLevelComponent , in base a quale abbiamo imparato che i componenti di alto livello hanno bisogno di quando li abbiamo programmati.

Ad esempio stiamo implementando un sistema che simula un'auto. Car è il componente di alto livello, mentre Engine e SteeringWheel sono i componenti di basso livello. Engine e SteeringWheel si prendono cura del lavoro concreto di spostamento della macchina, mentre Car si occupa di coordinare tutto e creare un sistema funzionante.

Se stessimo progettando il sistema in base al DIP, ciò significa che Engine e SteeringWheel sono definiti in termini di un'astrazione, che è definita in termini di ciò che è conveniente per Car .

Quindi sarebbe logico implementare prima Car , capire esattamente come funzionerà in termini di alto livello e cosa deve funzionare, e solo allora definire le interfacce IEngine e ISteeringWheel , secondo quanto il Car ha bisogno. E poi naturalmente implementare le classi concrete che implementano le interfacce.

Quindi quello che sto chiedendo è: quando si lavora su un progetto progettato nello spirito di DIP, l'approccio "dall'alto verso il basso" è comune? È così che di solito il lavoro viene svolto sul progetto seguendo il principio di inversione della dipendenza?

    
posta Aviv Cohn 30.04.2014 - 21:12
fonte

1 risposta

3

Di solito non è scritto nella pietra:

  • A volte può essere fatto così. Il componente di livello superiore ha bisogno di qualcosa, quindi l'interfaccia è progettata, quindi un oggetto mockup lo implementa, quindi lo sviluppo di un componente di livello superiore non deve attendere.

  • A volte lo sviluppo può essere fatto in entrambi i modi e incontrarsi nel mezzo.

  • Le interfacce non sono sempre definite da ciò che il componente più alto "ha bisogno", ad esempio un'interfaccia LightSource non avrà un metodo getPriceInDollars anche quando il componente di livello superiore sembra averne bisogno. Forse un'altra interfaccia avrà quel metodo getprice e alcuni implementor implementeranno entrambe le interfacce.

  • A volte i componenti e le interfacce esistenti vengono riutilizzati in un nuovo progetto.

  • A volte le classi esistenti, da progetti precedenti, possono essere realizzate per implementare nuove interfacce per essere conformi alla nuova architettura senza modificare i comportamenti o rompere i contratti precedenti, magari con l'uso di schemi di progettazione strutturale (Adattatore, Composito, Decoratore , ecc.)

  • A volte il componente di livello superiore si adatta semplicemente a qualsiasi interfaccia (classe astratta o interfaccia) del componente di livello inferiore, come quando si utilizza la libreria di terze parti. Il progettista della libreria (ad esempio una biblioteca per la creazione di grafici) pensava a un consumatore molto generico. E ciò non rende una tale biblioteca meno utile. NOTA: È ancora DIP perché stai programmando le astrazioni anche se una terza parte ha progettato queste astrazioni.

  • In OOD e OOP, i componenti di livello superiore non vengono sempre scritti per primi ei componenti di basso livello non vengono sempre scritti per ultimi. DIP ha il vantaggio aggiuntivo di non dover sviluppare rigorosamente in modo top-down o bottom-up.

  • I componenti di livello inferiore tendono ad amalgatare in API o librerie che sono trasversali ai progetti.

risposta data 30.04.2014 - 21:44
fonte

Leggi altre domande sui tag