Ornitorrinco
No todo lo que camina como un pato, nada como un pato y pone huevos como un pato, tiene necesariamente que ser un pato. Podría tratarse de un ornitorrinco, ¿verdad?Suponga que yo le digo que esto es Freya:
IStack = interface[X]
Count: Integer;
Top: X;
method Push(Value: X);
method Pop;
requires Count > 0;
IsEmpty: Boolean => Count = 0;
end;
Para que le resulte más fácil detectar el elemento extraño, utilizaré una sintaxis equivalente, algo más verbosa:
IStack = interface[X]
property Count: Integer;
property Top: X;
method Push(Value: X);
method Pop;
requires Count > 0;
property IsEmpty: Boolean;
begin
Result := Count = 0;
end;
end;
Y ahora, antes de subir la otra mitad del artículo, dígame si lo anterior le parece bien o mal...
Efectivamente, como mencionaba Marto en un comentario, se supone que las interfaces no "implementan". Sin embargo, es precisamente ese efecto lo que logran los métodos de extensión de C# 3.0:
interface IStack<X>
{
int Count { get; }
X Top { get; }
void Push(X value);
void Pop();
}
static class StackExt
{
public static bool IsEmpty<X>(this IStack<X> s)
{
return s.Count == 0;
}
}
Gracias a estos métodos, es posible escribir código como el siguiente, suponiendo que tenemos ya una clase que implementa el tipo de interfaz:
IStack<int> st = new StackImpl<int>();
if (st.IsEmpty()) { ... }
¿Es bueno, o es malo? No veo nada malo en permitir manipulaciones predefinidas sobre el estado "público" ofrecido por el contrato de la interfaz: lo mismo se puede lograr, incluso sin métodos de extensión, aunque al precio de escribir muchísimo más.
Ahora bien, mi duda va más allá. ¿Merece la pena implementar métodos de extensión (Freya ya los tiene), o sería suficiente con añadir al lenguaje implementaciones predefinidas en interfaces, como la del ejemplo de Freya? El caso es que los métodos de extensión son nada elegantes:
- El mecanismo de selección es horrible: basta con introducir una cláusula using para activarlos, dándole un protagonismo inapropiado a estas cláusulas.
- Estos métodos, cuando se emplean para extender una clase, plantean un grave problema de estabilidad respecto al versionado: si el implementador de la clase introduce un método de instancia en la clase extendida, dejará de funcionar la extensión, porque el método de instancia tiene la prioridad. Lo peor es que sería muy difícil detectar estos problemas.
De momento, a falta de más análisis, me inclino por sustituir este recurso por implementaciones en interfaces. Es verdad que no son recursos equivalentes, pero la suciedad de los métodos de extensión me aterra.
Etiquetas: extension methods, Freya, ideas, interface
Ian Marteens, 4:49 p. m.
6 comentarios
La implementación que hemos proporcionado a SaveChanges es mínima, y no es difícil encontrar casos para los que tendremos que complicarla. El primer ejemplo: la inserción de registros en tablas que contienen columnas con el atributo identity. De hecho, todas nuestras tablas tienen como clave primaria una columna con dicho atributo. Para entender en qué consiste el problema, sigamos el rastro de una inserción de registros. Supongamos que el usuario ha tecleado el siguiente registro para la tabla de países:
Ya está terminado el "Volumen I" del curso de ADO.NET, que incluye las series A, B y C completamente actualizadas. La serie B finalmente se ha quedado en unos pocos pero intensos ejercicios. Queda ahora "empaquetar" todo el contenido: vídeos, ejercicios y el manual del nuevo "volumen".
