Interfaces de "actualización"

Question

Hace un par de días vi el uso del CoClassAttribute de una forma que no había imaginado antes.

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

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

siendo utilizados como:

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

Eso debería no me han sorprendido desde el interoperabilidad COM hace exactamente eso desde los primeros días de .NET Framework. Simplemente no le he prestado tanta atención cuando exploro el código COM Interop en .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 
} 

Lo que pasa es que fuera del contexto de interoperabilidad COM, inmediatamente me imaginé esta siendo utilizado como inyección de dependencias en tiempo de compilación de un pobre hombre .

Todo lo que hay que hacer es deshacerse del prefijo "I" convencional en el nombre de la interfaz (al igual que COM Interop).

entonces sería una cuestión de cambiar el atributo Coclase para intercambiar una implementación para otro, burlándose, etc.

dos inconvenientes que veo por adelantado están teniendo que volver a compilar (que más o menos escenarios de prueba los límites de tiempo de desarrollo) y eventuales problemas que rodean las dependencias circulares cuando las interfaces y las implementaciones se implementan en diferentes conjuntos.

¿Alguien ha jugado con esta técnica? ¿Algún otro inconveniente? Otros usos?

Answer 1

Sé que esto obtuvo al menos dos publicaciones de blog en el fin de semana - mine y Ayende's.

Para la mayoría del código, esto debe tratarse simplemente como una curiosidad. Creo que sería un abuso usar esto para la inyección de dependencia, cuando los marcos de IoC/DI establecidos pueden hacer el trabajo mucho mejor, y tan simple.

En particular, este enfoque se basa en la compuerta de escape de §17.5, una extensión específica de Microsoft para la especificación ... ¿Desea que su código se ejecute en Mono? No lo he probado, pero no existe un motivo específico que deba compilarse bajo gmcs/dmcs.

Jon tenía un better example de usarlo en código concreto - para deliberadamente burlarse de COM, pero eso era para jugar con .NET 4.0/dynamic. De nuevo; esto no se aplicaría a la mayoría del código "regular".

Así que no; no lo hagas - es solo un divertido aparte.