Esto no parece posible? Entonces, ¿cuál es la mejor solución? Expando/dinámico?enviar tipo anónimo a una interfaz?
public interface ICoOrd {
int x { get; set; }
int y { get; set; }
}
...
ICoOrd a = new {x = 44, y = 55};
ref:
La mejor "solución alternativa" es crear y utilizar un tipo "nombrado" normal que implemente la interfaz.
Pero si insiste en que se use un tipo anónimo, considere usar un marco de proxy de interfaz dinámica como ImpromptuInterface.
var myInterface = new { x = 44, y = 55 }.ActLike<ICoOrd>();
No, los tipos anónimos nunca se implementan interfaces. dynamic tampoco le permitía enviar contenido a la interfaz, pero sería le permitía acceder a las dos propiedades. Tenga en cuenta que los tipos anónimos son internal, por lo que si desea usarlos en ensamblajes usando dynamic, necesitará usar InternalsVisibleTo.
+1: ty. Hice un poco de lectura en InternalsVisibleTo (enlace MS ahora en cuestión). Eso es útil. Parece un poco laborioso. ¿Has visto InternalsVisibleTo usado en el campo? – sgtz
@sgtz: ¿Trabajo intensivo? Es un atributo único. Se necesita un poco más de trabajo si está utilizando ensamblajes fuertemente tipados, pero de lo contrario es muy simple. Lo uso mucho para pruebas unitarias. –
@sgtz: InternalsVisibleTo se usa normalmente para pruebas unitarias; a veces desea realizar pruebas unitarias de una clase interna pero desea que el ensamblaje de prueba sea un ensamblaje diferente. De modo que le da acceso al conjunto de prueba a las partes internas. Raramente se usa en escenarios de código de producción. Recuerde, los ensamblados son * versionables *; ese es el * punto * completo de las asambleas. En la mayoría de los casos, no desearía * cambiar independientemente las versiones * de dos conjuntos * que se vean a los internos *. Si tiene dos asambleas que necesitan ver las internas de cada una, considere fusionarlas en una sola. –
Sé que esta es una vieja pregunta y mis respuestas, pero me encontré con esto en esto buscando hacer exactamente lo mismo para algunas pruebas unitarias. Entonces me di cuenta de que ya estoy haciendo algo como esto usando Moq (facepalm).
Me gusta la otra sugerencia para ImpromptuInterface, pero ya estoy usando Moq y siento que tiene un mayor número de seguidores (es decir, no es un hecho) será más estable y compatible durante más tiempo.
por lo que para este caso sería algo así como
public interface ICoOrd
{
int X { get; set; }
int Y { get; set; }
}
public class Sample
{
public void Test()
{
var aCord = new Mock<ICoOrd>();
aCord.SetupGet(c => c.X).Returns(44);
aCord.SetupGet(c => c.Y).Returns(55);
var a = aCord.Object;
}
}
EDITAR: simplemente añadiendo otra manera de burlar el cordón, comenzó a hacerlo de esta manera y al igual que un poco mejor.
public void AnotherTest()
{
var aCord = Mock.Of<ICoOrd>(c => c.X == 44 && c.Y == 55);
//do stuff with aCord
}
Solo tengo curiosidad: ¿qué intentas hacer que requiera que hagas esto? Si conoces la interfaz, obviamente sabes qué funcionalidad tiene la interfaz, por lo que puedes implementar una clase para proporcionar esa funcionalidad, en cuyo caso ya no necesitas un tipo anónimo, ya que puedes crear una instancia de tu clase. – xxbbcc
¿Por qué querría anonimizar (no le "importa" su diseño) a una interfaz (lo que significa que "se preocupa" por su diseño)? – gdoron
@gdoron: es útil tener una interfaz, y he descubierto que el buen uso de los tipos anon (sin LINQ en este caso) ha simplificado mi código * y * me ayudó a aclarar la intención. Esa es la motivación. Sobre todo para hacer con estructuras intermedias. – sgtz