Pourquoi existe-t-il un modèle d'interface / classe (IFoo, FooClass) dans l'API Office Interop?

Question

Dans la bibliothèque Microsoft.Office.Interop.Visio, chaque entité (par exemple, Shape) est décrite comme une classe (ShapeClass) et une interface, Shape.

Donc, pour chaque élément, vous avez:

interface Shape { ... }
class ShapeClass : Shape { ... }

interface Page { ... }
class PageClass : Page { ... }

...

Pourquoi est-ce conçu comme ça?

Answer 1

Le " Interop " une partie de l'espace de noms indique qu'il s'agit en fait d'une API basée sur COM.

COM était la première tentative de Microsoft d’établir un modèle de composant indépendant de la langue pour les développeurs. L’un de ses principes fondamentaux était la conception basée sur une interface.

Ainsi, dans votre exemple, ShapeClass est appelé une "co-classe", qui est une implémentation nommée de l'interface Shape .

Les co-classes étaient inscrites globalement (dans le registre Win32) et pouvaient être créées en fonction de leur nom convivial ("prog-ID") ou d'un GUID, appelé "CLSID".

Answer 2

Je suppose que ce sera parce qu'ils sont tous implémentés en tant qu'objets COM et que l'interface est là pour définir le contrat pour l'implémentation de la classe - les interfaces seront implémentées en IDL

wiki COM

Answer 3

Parce que c'est comme ça que COM fonctionne.

COM définit les interfaces implémentées par les composants. Presque tout dans COM est basé sur des interfaces. Les interfaces sont plus importantes que les classes qui les implémentent.

Answer 4

Ceci est basé sur le fonctionnement de COM.

Si vous recherchez des exemples de bonne conception .Net, consultez NON dans les bibliothèques d'interopérabilité Office (PIA). Ils encapsulent directement leur équivalent COM et sont moyennement affreux de travailler avec C #.

Pour faciliter l'utilisation des bibliothèques Office, essayez les Outils d'alimentation VSTO.