Perché esiste un modello di interfaccia / classe (IFoo, FooClass) nell'API di Office Interop?

Question

Nella libreria Microsoft.Office.Interop.Visio ogni entità (per esempio Shape), è descritta come una classe (ShapeClass) e un'interfaccia, Shape.

Quindi per ogni elemento che hai:

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

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

...

Perché è progettato in questo modo?

Answer 1

Il " Interop " parte dello spazio dei nomi suggerisce che si tratta in realtà di un'API basata su COM.

COM è stato il primo tentativo di Microsoft di creare un modello di componente indipendente dalla lingua per gli sviluppatori e uno dei suoi principi fondamentali era la progettazione basata su interfaccia.

Quindi, nel tuo esempio, ShapeClass è chiamato " co-class " ;, che è un'implementazione denominata dell'interfaccia Shape .

Le classi secondarie erano registrate a livello globale (nel registro di Win32) e potevano essere create in base al loro nome descrittivo ("ID prog" e ad un GUID, chiamato "CLSID".

Answer 2

Immagino che sarà perché sono tutti implementati come oggetti COM e l'interfaccia è lì per definire il contratto per l'implementazione della classe - le interfacce saranno implementate in IDL

wiki COM

Answer 3

Perché è così che funziona COM.

COM definisce le interfacce implementate dai componenti. Praticamente tutto in COM si basa su interfacce. Le interfacce sono più importanti delle classi che le implementano.

Answer 4

Questo si basa sul modo in cui funziona COM.

Se stai cercando esempi di un buon design .Net, NON cerca nelle librerie di interoperabilità di Office (PIA). Sono wrapper diretti attorno al loro equivalente COM e sono moderatamente terribili con cui lavorare in C #.

Per semplificare il funzionamento delle librerie di Office, provare VSTO Power Tools