Domanda

Questo è fondamentalmente lo stesso di Codifica alle interfacce, ma giocato nel mondo reale di 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.

Vengono forniti alcuni punti di estensione 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 Self: "Sembra che io possa reimplementare la maggior parte delle funzionalità (con algoritmi migliori), comprese quelle aree che non sono designate come estensibili". E così il programmatore lavora.

Solo quando l'implementazione del programmatore schiaccia (stile COM) con l'implementazione del sistema operativo e fallisce miseramente, il programmatore si è reso conto che il suite di oggetti Come implementato dal sistema operativo si basa fortemente sulle comunicazioni utilizzando interfacce non pubblicate, poiché l'interfaccia pubblicata era minimalista e ha bloccato molte opportunità di ottimizzazioni (*).

(*) Nelle attività di codifica/decodifica/trans-codifica (di dati dati/immagine/audio/video) G(F(x)) == x.

Un'interazione tipica è come:

  1. Il consumatore chiede al produttore se implementa un'interfaccia speciale x che solo il fornitore V lo sa.
  2. Se sì, il consumatore parla con il produttore usando l'interfaccia x e vedi se sono esatti opposti (n. 1).
  3. Se sì, il consumatore chiede al produttore il suo "stadio superiore" (cioè il produttore di bypassing) (n. 2) in modo che in effetti vengano annullati entrambi.

(#1) e (#2) sono capacità che mancano nell'interfaccia pubblicata minimalista. A prima vista sembra che Il venditore potrebbe avere la possibilità di fornirli anche.

Potrebbe anche essere il caso che fornire tali interfacce orientate alle prestazioni inquinerebbero gravemente lo spazio dei nomi.


Il risultato finale è che ogni volta che un programmatore fornisce la propria implementazione di una determinata classe, o) fallirebbe miseramente o (ii) funzionare molto lentamente, perché non poteva interagire con il resto del resto suite Usando le interfacce interne potenziate dalle prestazioni solo note a questo suite.

È un problema più frequente con alcuni sapori di tecnologia orientata agli oggetti? O è più comune con alcuni sapori dell'ingegneria basata sui 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 interfaccia. Per una certa tecnologia questo non è possibile.


Il modo in cui è importante è quello QueryInterface Il metodo consente la query di runtime (e la risposta di runtime) di interfacce aggiuntive implementate da una classe. Il suo equivalente Java sarebbe come una biblioteca che fa uso intenso instanceof Per interfacce interne al pacchetto.

Per i recensori: sono aperto a suggerimenti sul taglio della domanda alla sua essenza.

Il termine corretto sembra essere Mixin, Grazie a questo domanda.


Questo Rispondere è in parte rilevante, ma il mio esempio si concentra sulle opportunità perdute di ottimizzazioni all'interno di una singola biblioteca. Fondamentalmente, se un implementatore di terze parti non ha fatto entrambe le cose:

  1. Implementa sia encoder e decodificatore
  2. Implementare la propria interfaccia proprietaria sia su codificatore che decoder, al fine di rilevare e bypassare le operazioni che si annullano a vicenda

Quindi l'implementazione riceverà "prestazioni di base" solo quando si interferisce con diversi encoder/decodificatori da altri fornitori.

Nessuna soluzione corretta

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top