¿Por qué hay un patrón de interfaz / clase (IFoo, FooClass) en Office Interop API?

Question

En la biblioteca Microsoft.Office.Interop.Visio, cada entidad (por ejemplo, Shape) se describe como una clase (ShapeClass) y una interfaz, Shape.

Entonces, para cada elemento que tienes:

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

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

...

¿Por qué está diseñado así?

Answer 1

La "Interoperabilidad" parte del espacio de nombres sugiere que esta es realmente una API basada en COM.

COM fue el primer intento de Microsoft de crear un modelo de componente neutral para los desarrolladores, y uno de sus principios básicos fue el diseño basado en interfaz.

Entonces, en su ejemplo, ShapeClass se llama " co-class " ;, que es una implementación con nombre de la interfaz Shape .

Las co-clases se registraron globalmente (en el registro Win32) y se podían crear en función de su nombre descriptivo (" prog-ID ") o un GUID, llamado " CLSID " ;.

Answer 2

Supongo que será porque todos están implementados como objetos COM y la interfaz está ahí para definir el contrato para la implementación de la clase: las interfaces se implementarán en IDL

wiki COM

Answer 3

Porque así es como funciona COM.

COM define las interfaces que implementan los componentes. Casi todo en COM se basa en interfaces. Las interfaces son más importantes que las clases que las implementan.

Answer 4

Esto se basa en la forma en que funciona COM.

Si está buscando ejemplos de un buen diseño .Net, NO busque en las bibliotecas de interoperabilidad de Office (PIA). Son envoltorios directos alrededor de su equivalente COM y son moderadamente horribles para trabajar en C #.

Para facilitar el trabajo de las bibliotecas de Office, pruebe las VSTO Power Tools