（ab）使用 CoClassAttribute 为接口提供默认实现是否可以？答案

【问题标题】：Is it ok to (ab)use CoClassAttribute to provide a default implementation for an interface?（ab）使用 CoClassAttribute 为接口提供默认实现是否可以？
【发布时间】：2011-11-11 13:09:32
【问题描述】：

我最近发现"new up" an interface in C# 可以通过用CoClassAttribute 装饰接口来指定默认实现。

[ComImport, Guid("579A4F68-4E51-479A-A7AA-A4DDC4031F3F"), CoClass(typeof(FooImpl))]
public interface IFoo
{
    void Bar();
}

public class FooImpl : IFoo
{
    public void Bar() { }
}

...

// Constructs a FooImpl
IFoo foo = new IFoo();

我知道此功能的存在主要是为了支持 COM 互操作，但我想知道这是否是将接口与通用类库中的默认实现相关联的合理方法。

我有两个问题：

这样做有什么问题吗？我不是 COM 互操作方面的专家，我不知道这是否会对 POCO 产生任何负面影响。我没有运行任何主要测试，但我的示例中的 IL 似乎没问题（FooImpl 上的正常 newobj 指令，而不是对 Type.GetTypeFromCLSID 和 Activator.CreateInstance 的调用）。
即使这会顺利进行，是否还有其他原因（例如从 API 设计的角度）可以避免这种情况？

【问题讨论】：

当您使用 Windows 特定的东西时，单声道实现的代码可能已损坏。
隔着紧闭的门都能听到wtfs的弹幕，应该是足够的理由了。您最好对其进行概要分析。
这真的能完成工厂做不到的事情吗？

标签： c# .net com api-design coclass

【解决方案1】：

您不应该这样做的关键原因是您正在对不需要它的对象实例启动 COM 生命周期管理。 .NET 现在必须进行一些 COM 互操作，包括安全堆栈遍历、单元线程检查和 addref/release 内容。

相反，我会考虑查看依赖注入（控制模式反转）和公共服务定位器模式。我将专注于理解构造函数注入，因为它是依赖管理的首选模式。

这是我在我的库中所做的。假设我想编写一个日志服务（人为的例子）。我将有两个核心组件：

MyStuff.Logging.Contracts - 这里是我声明 ILogger 接口的地方 MyStuff.Logging - 在这里我可以编写不同的日志记录实现，例如 FileLogger、DatabaseLogger 等。

然后在我的应用程序中，我将使用 Ninject 或 Unity（DI 容器）将 ILogger 与默认实现相关联。

【讨论】：

谢谢。即使在纯 .NET 环境中，运行时真的会仅仅因为存在这些属性就完成所有这些工作吗？你能给我提供一些这方面的信息吗？
看看这个：msdn.microsoft.com/en-us/library/…。 “ComImportAttribute 是一个伪自定义属性，表示已在以前发布的类型库中定义了一个类型。公共语言运行库在激活、导出、强制等时以不同方式处理这些类型。”
虽然使用 new 运算符最终可能只是调用构造函数。我认为运行时必须进行生命周期管理和线程单元管理，否则该类实际上不是 COM 对象。

【解决方案2】：

使用智能感知 cmets：

    /// <summary>
    /// Explain here all about interface
    /// </summary>

而不是破解属性，因为它可能会在使用您的类的其他人的半反射实现中适得其反。属性供使用反射的工具使用，智能感知用于文档。

当然，一些旧版工具在读取您的 /// cmets 时会出现问题，但它们也无法读取您的属性。

【讨论】：

这个问题不是关于 cmets，而是一个接口的默认实现。
很好，投反对票总是好的，但我感谢您没有匿名这样做。无论如何，问题是。 “这样做有什么问题吗？”我回答了它，还提出了一个正确的方法来解决他的问题......