CoClassAttributeを使用して（ab）インターフェイスのデフォルトの実装を提供することはできますか？

Question

私は最近、"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-相互運用をサポートするために主に存在していることを承知しているが、これは一般的なクラス・ライブラリのデフォルトの実装とのインターフェイスを関連付けるための合理的な方法だろうかと思いまして。

1. がこれを行うと任意の落とし穴があります：

   私は2つの質問がありますか？私はCOM-interopの専門家ではなく、これがPOCOに何らかの悪影響を及ぼすかどうかはわかりません。私は大きなテストは行っていませんが、私の例ではILはとActivator.CreateInstanceを呼び出すのではなく、newobj命令（FooImpl）であるようです。

2. これがスムーズに機能する場合でも、これを避けるために他の理由がありますか（API設計の観点から）？

Answer 1

使用intelisenseコメント：

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

ではなく、それはあなたのクラスを使用して誰か他の人の半反射実装に裏目に出る可能性があるとして、属性をハッキング。属性は、リフレクションを使用するツールで使用されるため、インテリセンスはドキュメント化用です。

許可されているレガシーツールの中には///コメントの読み込みに問題がありますが、あなたの属性を読み取ることはできません。

Answer 2

これを行うべきではない主な理由は、COMライフサイクル管理を必要としないオブジェクトのインスタンスで開始することです。 .NETでは、セキュリティスタックウォーク、アパートメントスレッドチェック、addref/releaseなどのCOM相互運用機能が必要になります。

代わりに、依存性注入（制御パターンの反転）と共通サービスロケータパターンを検討することを検討します。私はそれが依存関係管理のための好ましいパターンであるので、コンストラクタインジェクションを理解することに焦点を当てるでしょう。

ここで私のライブラリで何をしています。ロギングサービスを作成したいと考えてみましょう。

MyStuff.Logging.Contracts - ここでILoggerインターフェイスを宣言します。 MyStuff.Logging - ここで、FileLogger、DatabaseLoggerなどのさまざまなログ実装を記述します。

私のアプリケーションでは、NinjectまたはUnity（DIコンテナ）のいずれかを使用して、ILoggerをデフォルトの実装に関連付けることになります。