L'implémentation globale d'un composant peut-elle être divisée en deux objets?

Question

J'ai vu avec Microsoft COM et XPCOM, au moins d'après ce que j'ai lu et rassemblé jusqu'à présent, que les implémentations d'interfaces dans un composant doivent essentiellement se faire dans la classe unique qui dérive toutes les interfaces virtuelles. Est-ce correct? Qu'est-ce que je rate?

Existe-t-il un moyen d'avoir plusieurs objets (éventuellement dans des DLL séparées) chacun fournissent leur fonctionnalité et être toujours en mesure de passer librement entre eux en utilisant QueryIterface? Ce que je cherche, c'est avoir un composant avec certaines fonctionnalités, mais permettre au code client externe de créer de nouvelles extensions du composant avec (éventuellement) de nouvelles interfaces. Idéalement, cela devrait se faire sans divulguer la source actuelle du composant et sa mise en œuvre.

Answer 1

Cela devrait être possible, même s'il n'est probablement pas pris en charge par les wrappers de haut niveau standard. La plupart des wrappers (ATL, MFC, etc.) prennent uniquement en charge le mappage d'un objet COM à une seule classe. Toutefois, QueryInterface est autorisé à renvoyer un pointeur différent et appelle le code objet COM, de sorte que le premier objet COM peut charger une DLL différente, instancier un objet différent et renvoyer un pointeur vers son interface (vtable).

Tout est possible, autant que je sache, vous allez probablement écrire vous-même beaucoup de code de colle de bas niveau.

Answer 2

Oui, ATL prend en charge tear-off interfaces Cela permet de créer l'interface dans une autre classe qui est instanciée uniquement lorsque l'interface est demandée. Comme il ne passe qu'une interface, je suppose qu'il peut aussi être placé dans une DLL séparée.

(peut également être cached après avoir été demandé une fois)