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.