Hola a todos!
Me animo a escribir pues hace poco estaba leyendo unos artículos de Test Driven Development (TDD) y por casualidad encontré uno que me ha motivado a investigar más sobre algo que ya todos conocemos, Diseño por Contrato (DbC).
La verdad es que no se cuantos de uds. están usando TDD o no; y se que solamente este tema abarcaría un muy interesante intercambio en el blog; pero el objetivo principal de este post (y los posteriores que pretendo publicar) es enfocarnos en conocer lo que ya se ha logrado con DbC utilizando C#.
En este artículo no se explica en profundidad ninguna de las dos técnicas. Y la idea es hacer notar como podemos mejorar una usando la otra.
Espero que les guste y les motive tanto como a mi. Aquí va el artículo: http://www.codeproject.com/KB/architecture/DbCwithXCSharp.aspx
A mi entender, XC# no es la mejor herramienta para utilizar DbC, pero lo que creo importante en este artículo no es la herramienta, sino los conceptos.
Sobre un mejor acercamiento a DbC en C# tratará el próximo post.
Noten en las alternativas a XC# como se hace referencia a nuestro querido Miguel Katrib.
Happy programming, not debugging!
Erlis
Suscribirse a:
Enviar comentarios (Atom)
3 comentarios:
Casi todos estos frameworks en C# se basan en las declaraciones de atributos. .NET en particular cuenta con una clase muy peculiar, ContextBoundObject, que genera un proxy para casi todas las llamadas a métodos y a properties en el objeto, el cual se puede intervenir mediante un sink.
El mecanismo es clásico, algo complicado pero muy interesante. Los decoradores (ejemplo: [PropertyName=Value] ) generan propiedades, y éstas pueden contribuir a la cadena de ejecución en el sink. Al manejar el sink de eventos, se tiene total control de lo que sucede antes, durante y después del acceso al método o la propiedad en cuestión. - No creo que sirva para variables, aunque casi ninguna metodología de software recomienda exponer variables públicas.
El único requisito en .NET es heredar de esa clase. Otros frameworks como Spring, para Java, tengo entendido que generan un pseudo-compilado detrás de los bastidores, para generar el código final con toda la cadena de reglas.
Sin duda es un tema muy interesante el que has tocado. También entre las utilidades concretas de Aspect Programming, están los context-loggers, (la idea es, con sólo decorar apropiadamente una clase o un método, éste activará una secuencia de logs).
LINQ, (creo que también) NHibernate y otros ORM utilizan intensivamente el Aspect Programming para representar objetos contra la capa de persistencia, decorando las clases y las columnas contra las tablas y los campos específicos en la base de datos (ejemplo, TableName, FieldName, etc...), aunque no tocan para nada el sink de eventos, sino que dejan la labor a los Data Contexts, que son los encargados de generar las secuencias correctas de SQL para los cambios. LINQ tiene para ello un par de interfaces declarando eventos para notificar a los data contexts de cada vez que una propiedad cambió de valor.
Volviendo al tema inicial de la programación por contrato, yo estuve programando, hace unos meses atrás, hacer algo como lo que tiene Eiffel de las pre-post-invariantes, y logré algo pero con la única condición de que la función tuviera un signature predeterminado, (ej. bool Verify() ), llamándola mediante reflection. En .NET, la única restricción para poder tener objetos self-aware es heredar de la clase ContextBoundObject. No terminé de desarrollar la idea, pero fue un ejercicio bastante interesante.
Buen tema, saludos.
Hola humbert,
Que bueno recibir tu comentario, ya estaba pensando que nadie habia leido el post.
Lo mejor de todo es que precisamente estuviste haciendo algo al respecto, esto va a ayudarnos muchos a todos con tus comentarios.
Como bien dices, casi todos los frameworks en C# se basan en declaraciones de atributos, y esto hace que la utilizacion de DbC en C# deje mucho que desear. Ya estaba preparando el proximo post para el grupo y es precisamente sobre este tema, un "mejor" framework para utilizar DbC.
Tal vez me desvie del tema original que es la introduccion de DbC en TDD pero creo que vale la pena darle un vistazo al framework antes y luego si creemos que vale la pena (me incluyo) entonces podemos seguir investigando.
Hasta el proximo post/comentario.
Erlis
Hola Erlis,
Pienso que jamás ningún lenguaje de programación tendrá aquellos fancy features de Eiffel como los:
ensure: old Value = new Value
Y otras cosas por el estilo. Quizás eso hizo que fuera tan difícil que Eiffel tuviera compiladores decentes.
Por cierto, no sé si has visto Envision. Es un plugin para .NET que utiliza el CLR, y se puede utilizar desde Visual Studio. Lo bajé una vez, pero te confieso que no le dediqué mucho tiempo. Envision es un compilador de Eiffel. Tengo entendido que Ada, Prolog y otros lenguajes también han resucitado gracias a estas nuevas herramientas de desarrollo de Microsoft.
Sólo quería mencionarte lo de Envision. Si te pica la el bichito de programar en Eiffel, lo puedes bajar gratis.
Tan sólo te recomiendo que no les hagas mucho caso a los entusiastas del blog de Envision, son un poco engreídos y piensan que lo que ellos tienen es lo mejor del mundo y si les señalas algún punto flaco te van a crucificar, jejeje.
Eiffel sin dudas sentó pautas, pero como todos los lenguajes de programación tiene sus ventajas y también sus desventajas.
Saludos de nuevo.
Publicar un comentario