Questo è fondamentalmente lo stesso di Coding to interfaces , ma giocato nel mondo reale di com quando ci sono varie complessità ingegneristiche come l'immutabilità delle interfacce e delle implementazioni pubblicate, ecc.
Considera la seguente situazione:
Una libreria orientata agli oggetti a livello di sistema operativo con una serie di interfacce pubblicate e un'implementazione fornita dal sistema operativo.
Alcuni punti di estensione sono forniti in modo che terze parti possano estendere comportamenti specifici implementando un sottoinsieme delle interfacce pubblicate e registrandole con il sistema operativo.
Un programmatore esamina l'intera serie di interfacce pubblicate e dice a se stesso, "sembra che io possa ri-implementare la maggior parte delle funzionalità (con algoritmi migliori), comprese quelle che non sono designate come estensibili." E così il programmatore lavora.
Solo quando l'implementazione del programmatore si trasforma in stile COM con l'implementazione del sistema operativo e fallisce miseramente, il programmatore si è reso conto che la suite di oggetti implementata dal sistema operativo si basa molto sulle comunicazioni che utilizzano interfacce non pubblicate, perché l'interfaccia pubblicata era minimalista e bloccava molte opportunità di ottimizzazione (*).
(*) Nei compiti di codifica / decodifica / codifica (di dati / immagine / suono / compressione video), è noto che determinati stadi di condotte possono annullarsi a vicenda se eseguono l'operazione esattamente opposta / inversa, ad es. G(F(x)) == x .
Un'interazione tipica è come:
- Il consumatore chiede al produttore se implementa un'interfaccia speciale X che solo il venditore V conosce.
- Se sì, Consumer parla con Producer usando l'interfaccia X e verifica se sono esattamente opposti (# 1).
- Se sì, il Consumatore chiede al produttore il suo "livello superiore" (cioè bypassando Producer) (n. 2) in modo che entrambi vengano annullati.
(# 1) e (# 2) sono funzionalità che mancano nell'interfaccia di pubblicazione minimalista. A prima vista sembra che il venditore possa avere la possibilità di fornirli, ma scegliere di non .
Potrebbe anche essere il caso che fornire tali interfacce orientate alla prestazione danneggi gravemente lo spazio dei nomi.
Il risultato finale è che ogni volta che un programmatore fornisce la propria implementazione di una certa classe, o (i) fallisce miseramente, o (ii) esegue molto lentamente, perché non potrebbe interagire con il resto della suite utilizzando le interfacce interne con prestazioni migliorate conosciute solo da quella suite .
Si tratta di un problema più frequente con alcuni sapori della tecnologia Object-Oriented? O è più comune con alcuni sapori di ingegneria basata su componenti?
I sostenitori di OOP sosterranno che il refactoring e la pubblicazione di tali interfacce risolverebbero il problema. Ciò presuppone che sia possibile distribuire una nuova versione della libreria insieme a una nuova serie di interfacce. Per alcune tecnologie questo non è possibile.
Il modo in cui conta com è che è QueryInterface consente la query run-time (ed esegue risposta temporale) di interfacce aggiuntive implementate da una classe. Il suo equivalente Java sarebbe come una libreria che fa un uso pesante di instanceof per le interfacce interne al pacchetto.
Ai revisori: sono aperto a suggerimenti su come tagliare la domanda alla sua essenza.
Il termine corretto sembra essere Mixin , grazie a questo domanda .
Questa risposta è parzialmente pertinente, ma il mio esempio si concentra sulle opportunità perse per le ottimizzazioni all'interno di una singola libreria. In sostanza, se un implementatore di terze parti non ha fatto entrambe le cose:
- Implementa sia il codificatore che il decoder
- Implementa la propria interfaccia proprietaria sia sull'encoder che sul decoder, al fine di rilevare e bypassare le operazioni che si annullano a vicenda
Quindi l'implementazione otterrà solo "prestazioni di base" quando interagirà con codificatori / decodificatori diversi da altri fornitori.