Creazione di campi interfaccia per iniettare vs Oggetti?

Question

Creazione di campi interfaccia per iniettare vs Oggetti?

#1 da (4 voti)

2

Nel tutorial lo sto facendo usa le interfacce per iniettare cose, ad esempio usa un'interfaccia IHotDrink , quindi crea una classe Tea che implementa IHotDrink . Ha quindi una terza classe chiamata Ristorante che ha un campo IHotDrink all'interno della classe e assegna un valore ad esso nel costruttore. In seguito, inserisce una Classe di tè nel costruttore della classe Restaurant (che accetta un argomento dell'interfaccia di IHotDrink)

Quindi fondamentalmente la mia domanda è: ogni campo che verrà iniettato deve essere un'interfaccia?

Diciamo che ho un sacco di prodotti alimentari che implementano un'interfaccia IHotFoods e un mucchio di bevande che implementano tutte l'interfaccia IHotDrink , sarebbe ok se Ho una classe pasto che non implementa nulla e utilizza un'interfaccia IHotFood e un'interfaccia IHotDrink come argomenti nel suo costruttore (che in seguito essere iniettato da diversi corsi di cibo / bevande e poi avere un campo pasto nella classe ristorante che posso iniettare con diversi oggetti pasto? Questo andrebbe bene? O dovrei: Interagire con i pasti, consumare pasti e fare in modo che il ristorante abbia un campo di interfaccia per i pasti in cui posso inserire del cibo?

Modifica: non sto chiedendo se ogni classe dovrebbe implementare un'interfaccia, sto chiedendo se devono sempre avere campi di interfaccia per iniettare altre classi in loro che implementare anche l'interfaccia. (come nell'esempio nel tutorial)

dependency-injection java spring

posta Larvitar 30.12.2017 - 08:54

fonte

1 risposta

Leggi altre domande sui tag dependency-injection java spring

Implementazione del paging con più origini dati Estratto differenze di configurazione di fabbrica

score 4 · Accepted Answer

Ciò che stai osservando è in realtà chiamato "codifica su un'interfaccia".

Come l'iniezione di dipendenza, è una tecnica per mantenere il codice liberamente accoppiato. Ecco perché tendi a vederli usati insieme.

Ora, per rispondere alla tua domanda: No, non è sempre necessario memorizzare le dipendenze iniettate come interfacce. Puoi archiviarli come tipi concreti, ma ciò accoppiare strettamente la tua classe dipendente alla sua dipendenza (che in genere è una cosa negativa).

Spesso memorizzo le mie dipendenze come tipi concreti mentre sono nelle prime fasi della codifica della mia applicazione. Lo faccio, perché è probabile che la struttura del mio codice cambi molto, quindi estrarre un'interfaccia e mantenerla aggiornata può essere un problema. Ma, una volta che la struttura del mio codice si è stabilizzata, tendo a passare di nuovo e sostituisco i riferimenti a tipi concreti con riferimenti a interfacce in cui ritengo che l'accoppiamento libero sia importante.

Nel tuo esempio specifico, l'interfaccia potrebbe essere effettivamente implementata da molte diverse bevande calde. Il motivo per cui la classe Restaurant lo memorizza come IHotDrink è perché non gli interessa quale bevanda calda specifica riceve. Ho solo bisogno di sapere che ciò che riceve si comporta come (leggi: ha l'interfaccia di) una bevanda calda. Quindi, archiviarlo come un tipo concreto in questo caso non ha senso. Restringerebbe inutilmente ciò che il tuo Restaurant può offrire.

Per quanto riguarda la tua idea di classe Meal , ciò potrebbe avere senso, ma a seconda delle responsabilità della tua classe Restaurant potrebbe essere troppo restrittivo. Un Restaurant offre solo pasti fissi? O consente agli utenti di scegliere e combinare cibi caldi e bevande calde? Inoltre, un Restaurant consentirà agli utenti di acquistare singoli articoli e pasti completi? Sarebbe un peccato dover comprare un hamburger se tutto quello che volevo fosse un caffè:)