Kilka dni temu widziałem, jak CoClassAttribute jest używany w sposób, jakiego wcześniej nie wyobrażałem sobie.

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

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

używane jako:

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

To nie powinno mnie dziwić, ponieważ COM Interop robi dokładnie to od początku istnienia .NET Framework. Po prostu nie zwracałem na to uwagi podczas kopania kodu COM Interop w .NET Reflector.

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 
}

To, co się wydarzyło, to fakt, że poza kontekstem COM Interop od razu wyobrażałem sobie, że jest to używanewstrzyknięcie zależności czasu biednego człowieka.

Wszystko, co musisz zrobić, to pozbyć się konwencjonalnego przedrostka „I” w nazwie interfejsu (podobnie jak COM Interop).

Wówczas byłoby kwestią zmiany atrybutu CoClass, aby zamienić implementację na inną, szyderstwo itp.

Dwie wady, które widzę z góry, to konieczność ponownej kompilacji (co znacznie ogranicza scenariusze testowania do czasu rozwoju) i ewentualnych problemów związanych z zależnościami cyklicznymi, gdy interfejsy i implementacje są wdrażane na różnych zespołach.

Czy ktoś grał tą techniką? Jakieś inne wady? Inne zastosowania?