在Microsoft.Office.Interop.Visio 库中,每个实体(例如Shape)都被描述为一个类(ShapeClass)和一个接口Shape。
因此,对于您拥有的每个元素:
interface Shape { ... }
class ShapeClass : Shape { ... }
interface Page { ... }
class PageClass : Page { ... }
...
为什么会这样设计?
在Microsoft.Office.Interop.Visio 库中,每个实体(例如Shape)都被描述为一个类(ShapeClass)和一个接口Shape。
因此,对于您拥有的每个元素:
interface Shape { ... }
class ShapeClass : Shape { ... }
interface Page { ... }
class PageClass : Page { ... }
...
为什么会这样设计?
命名空间的“互操作”部分暗示这实际上是一个基于 COM 的 API。
COM 是微软首次尝试为开发人员提供语言中立的组件模型,其核心原则之一是基于接口的设计。
因此,在您的示例中,ShapeClass
它被称为“co-class”,它是Shape
接口的命名实现。
共同类是全局注册的(在 Win32 注册表中),并且可以根据它们的友好名称(“prog-ID”)或称为“CLSID”的 GUID 创建。
我想这将是因为它们都是作为 COM 对象实现的,并且接口在那里定义类实现的合同 - 接口将在 IDL 中实现
因为这就是 COM 的工作方式。
COM 定义了组件实现的接口。COM 中的几乎所有内容都基于接口。接口比实现它们的类更重要。
这是基于 COM 的工作方式。
如果您正在寻找良好的 .Net 设计示例,请不要查看 Office 互操作库 (PIA)。它们是其 COM 等效项的直接包装器,并且在 C# 中使用起来相当糟糕。
要使 Office 库更易于使用,请尝试使用VSTO 电动工具