"Newing up" Interfaces

Question

数日前、CoClassAttributeが私が以前想像していない方法で使用されているのを見ました。 COM相互運用機能は、.NET Frameworkの初期の頃以来、まさにそのため、私を驚かせていないはずです

class CoClassDemo { 
    public static void Show() { 
     var a = new IFoo(); 
     a.Bar(); 
    } 
} 

：として使用されて

[ComImport, CoClass(typeof(Foo)), Guid("787C1303-AE31-47a2-8E89-07C7257B1C43")] 
interface IFoo { 
    void Bar(); 
} 

class Foo : IFoo { 
    public void Bar() { 
     Console.WriteLine("Oh retado!"); 
    } 
} 

。 .NET ReflectorのCOM Interopコードを掘り下げる際には、あまり注意を払っていません。何が起こった

method public hidebysig static void Show() cil managed 
{ 
    .maxstack 1 
    .locals init (
     [0] class ConsoleApplication1.IFoo a) 
    L_0000: nop 
    L_0001: newobj instance void ConsoleApplication1.Foo::.ctor() 
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: callvirt instance void ConsoleApplication1.IFoo::Bar() 
    L_000d: nop 
    L_000e: ret 
} 

は、COM相互運用機能の文脈の外に、私はすぐに私はこれが貧乏人のコンパイル時の依存性注入として使用されている想定ということです。

すべては、インターフェイスの名前に従来の「I」という接頭辞を取り除くことです（COM Interopと同様）。

その後、それは私が先行参照

2つの欠点は、（開発時間にどのかなりの制限のテストシナリオ）を再コンパイルする必要がされているなど、あざける、別の実装を交換するのCoClass属性を変更することの問題だろうインターフェイスと実装が異なるアセンブリにデプロイされているときの循環依存を取り巻く最終的な問題です。

誰もこの手法で遊んだ人はいますか？ 他の欠点はありますか？ 他の用途は？

Answer 1

週末に少なくとも2つのブログ投稿があることを知っています - mineとAyende'sです。

ほとんどのコードでは、これは単に好奇心として扱う必要があります。私は、IoC/DIフレームワークを確立することで、その作業をはるかに上手くやり遂げることができるようになると、これを依存性注入に使用することが濫用になると思います。

特に、このアプローチでは、Microsoft固有の拡張仕様である§17.5のエスケープハッチに依存しています。コードをMono上で実行したいですか？私はそれを試していないが、特定の理由 gmcs/dmcsでコンパイルする必要はありません。

Jonは具体的なコードでそれを使用していました。意図的にCOMを嘲笑するためでしたが、それは.NET 4.0/dynamicで対処するためのものでした。再び;これはほとんどの「通常の」コードには当てはまりません。

です。 do not do - それはちょっと面白いです。