Quando l'interfaccia dovrebbe essere di proprietà del cliente?

4

In Sviluppo software agile: principi, modelli e pratiche , Uncle Bob parla del client che possiede l'interfaccia di servizio.

Le mie domande sono:

  1. Il client dovrebbe sempre possedere l'interfaccia o solo quando il client cambia meno spesso ad un livello più alto di astrazione rispetto alle classi che implementano l'interfaccia?

  2. Esiste uno scenario in cui il client deve possedere l'interfaccia sebbene si trovi a un livello di astrazione più basso rispetto alle classi di implementazione.

Modifica: il client che possiede l'interfaccia significa che specificherà l'interfaccia e non gli implementatori dell'interfaccia. Gli implementatori dell'interfaccia possiedono l'interfaccia nel caso di librerie di utilità.

    
posta q126y 16.12.2015 - 15:51
fonte

1 risposta

6

In primo luogo, chiariamo cosa intendiamo quando diciamo che "l'interfaccia è di proprietà del cliente". Significa che l'interfaccia è definita da quale client dell'interfaccia ha bisogno e non da ciò che fornisce l'implementatore. Se dovessimo creare un modulo del trio di client , interface e implementer , il primo modulo sarebbe client e interface e il secondo sarebbe implementer , con il secondo modulo a seconda del primo uno. Ciò si adatta perfettamente ai principi di Inversione di dipendenza e Principi di separazione dell'interfaccia.

Detto questo, credo che "l'interfaccia è di proprietà del cliente" è la posizione predefinita in buona progettazione. La domanda dovrebbe essere "Ha senso che l'interfaccia sia definita dall'implementatore". Per me, la domanda è no. Ci sono molte ragioni per questo.

Per prima cosa, esaminiamo i modelli di design GoF:

Qui, è abbastanza ovvio, che ogni interfaccia non è definita dall'implementatore, ma dal client. Ogni modello consente numeri e tipi di implementatori arbitrari. Ma se il cliente cambia, anche l'interfaccia. Ciò significa che l'interfaccia e il client sono più strettamente concettuali di un'interfaccia e un implementatore.

Il secondo è già menzionato principio Segregazione interfaccia. Dice "Il client non dovrebbe dipendere dall'interfaccia di cui non ha bisogno". Questo può essere parafrasato come "L'interfaccia è definita da ciò che il cliente ha bisogno". Questo è abbastanza chiaro.

Terzo è la logica dietro l'interfaccia che viene definita dall'implementatore. Se l'interfaccia è definita dall'implementatore, diventa molto facile perdere l'API dell'installatore specifico. Ciò renderà difficile fornire implementazioni diverse per l'interfaccia. È abbastanza comune vedere un singolo implementer per un'interfaccia se tale interfaccia è definita da quell'implementatore. Qual è allora il punto in questo?

Riassumendo : in interfacce di progettazione buone, modulari e comprensibili (e altre astrazioni) sono prima di tutto definite dalle esigenze dei clienti e quindi parte di esse. È un odore di codice se l'interfaccia è definita da ciò che fornisce l'implementatore.

    
risposta data 18.12.2015 - 11:08
fonte