Why is there interface / class (IFoo, FooClass) pattern in Office Interop API?

Question

In the Microsoft.Office.Interop.Visio library each entity (for e.g Shape), is described as a class (ShapeClass) and an interface, Shape.

So for each element you have:

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

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

...

Why is it designed like this?

Answer 1

I guess it will be because they are all implemented as COM objects and the interface is there to define the contract for the class implementation - the interfaces will be implemented in IDL

wiki COM

Answer 2

Because that's how COM works.

COM defines interfaces that components implement. Pretty much everything in COM is based on interfaces. The interfaces are more important than the classes that implement them.

Answer 3

This is based on the way COM works.

If you're looking for examples of good .Net design, do NOT look in the Office interop libraries (PIAs). They are direct wrappers around their COM equivalent and are moderately awful to work with in C#.

To make the Office libraries easier to work with, try the VSTO Power Tools

Answer 4

The "Interop" part of the namespace hints that this is actually a COM-based API.

COM was Microsoft's first attempt at a language-neutral component model for developers, and one of its core tenets was interface-based design.

So, in your example, ShapeClass is called a "co-class", which is a named implementation of the Shape interface.

Co-classes were registered globally (in the Win32 registry) and could be created based on their friendly name ("prog-ID") or a GUID, called "CLSID".