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

Question

我最近发现，通过使用CoClassAttribute接口以指定默认实现，可以在C＃中“新建”接口 。

[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-interop，但我想知道这是否是将接口与泛型类库中的默认实现相关联的合理方法。

我有两个问题：

1. 这样做有什么陷阱吗？ 我不是COM-interop的专家，我不知道这是否会对POCO产生任何负面影响。 我没有运行任何主要测试，但我的示例的IL似乎没问题（在FooImpl上的普通newobj指令，而不是调用Type.GetTypeFromCLSID和Activator.CreateInstance ）。

2. 即使这样可以顺利运行，还有其他原因（例如从API设计的角度来看）避免这种情况吗？

Answer 1

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

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

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

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

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

Answer 2

使用知识产权评论：

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

而不是黑客攻击属性，因为它可能适用于使用你的类的其他人的半反射实现。 属性可供使用反射的工具使用，而智能则用于文档。

当然，一些遗留工具在阅读您的///注释时会遇到问题，但它们也无法读取您的属性。