Quale design pattern descrive meglio il pattern queryInterface di COM?
Nella programmazione COM, ogni oggetto COM espone un queryInterfacemetodo. Gli si fornisce un tipo con cui si desidera "eseguire il cast" dell'oggetto COM e, se lo supporta, restituirà un riferimento alla sua implementazione del tipo richiesto.
È un po 'come un registro di servizio, ma c'è una pseudo-semantica secondo cui tutte le interfacce a cui puoi eseguire il cast di un determinato oggetto sono interfacce per lo stesso oggetto, piuttosto che una costellazione di istanze correlate e collegate come avresti normalmente in un servizio localizzatore.
In Java potrei fare in modo che una classe implementi più interfacce e usi semplicemente il linguaggio per eseguire il cast avanti e indietro. Ma mi interessa che un oggetto sia in grado di decidere dinamicamente se può fornire un'interfaccia o un adattatore del tipo richiesto, piuttosto che averlo deciso staticamente.
C'è un nome per questo modello di progettazione in cui interroghi un oggetto per una rappresentazione di se stesso come un dato tipo?
Risposte
Sì, c'è un nome per questo, e sono sicuro che lo conosci già: si chiama Reflection , ed è stato menzionato come modello architettonico nel libro Pattern Oriented Software Architecture # 4 .
Naturalmente, il termine "Riflessione" ha un significato più ampio della semplice disponibilità di un queryInterfacemetodo di interfaccia. Copre sistemi che forniscono tutti i tipi di introspezione di tipo dinamico . "Interrogare un oggetto per una rappresentazione di se stesso come un dato tipo" è solo un modo possibile per implementare una specifica funzione di introspezione. Quindi "introspezione" può anche essere un termine appropriato.
Non mi spingerei così lontano a dire "COM si basa su questo modello". Questa è una proprietà di COM (tra le altre), sicuramente importante, ma non l'unica o primaria.
COM QueryInterfaceè un'implementazione a livello di libreria del casting dinamico (controllato).
Non esiste alcun modello di progettazione che descriva ciò perché i modelli di progettazione sono in genere soluzioni per problemi che non hanno una soluzione banale a livello di linguaggio. Il casting dinamico, tuttavia, ha una banale soluzione a livello di linguaggio nella maggior parte delle lingue.
Tuttavia, dato che lingue diverse supportano funzionalità diverse, la linea tra le caratteristiche del linguaggio e gli schemi di progettazione può essere sfocata. Ad esempio, il modello di comando è praticamente un'implementazione a livello di libreria di chiusure di prima classe. Più concretamente, IIRC Scala ha un'implementazione a livello di linguaggio di Singleton.
Ciò significa che la prima frase di questa risposta è una descrizione sufficiente della funzionalità, anche se probabilmente non troverai "Dynamic Cast" in nessun elenco di design pattern.
OTOH, il meccanismo abilitato da QueryInterfacee il modo in cui viene tipicamente utilizzato, è praticamente il "Capability Pattern" descritto da questo articolo:https://dzone.com/articles/the-capability-pattern-future-