Lucas Ontivero : Patrones

Design patterns in the test of time: VISITOR

Lucas Ontivero — Tue, 30 Oct 2012 04:46:00 GMT

@Ayende ha comenzado una serie de post en lo que revisa algunos patrones de diseño (Go4) luego de transcurridos más de 18 años desde su formalización en el libro Design Patterns: Elements of Reusable Object-Oriented Software. Inspirado por esa serie, y por el hecho de que en mi última entrevista laboral me preguntaron sobre esto, voy a presentar una revisión sobre el patrón visitor.

Visitor en su forma clásica

La motivación detrás de este patrón es poder añadir funcionalidad a una estructura de datos sin necesidad de modificar las clases que conforman esa estructura. En otras palabras: separar las estructuras de datos de aquellos algoritmos que operan sobre ellas. Si vamos a la Wikipedia vamos a ver este diagrama:

Technorati Tags: Design,Pattern,Visitor

Como se ve, tiene referencias cíclicas, es decir, todos los CarElements deben implementar un método accept que recibe una referencia a un CarElementVisitor y todo CarElementVisitor matiene referencias a todos los tipos que implementan la interface CarElement. Esto es porque C# (el diagrama usa java) no posibilida doble dispatch y así, mediante estas referencias cíclicas es cómo se logra simularla.

Aparte del fuertísimo acoplamiento al que nos fuerza, tiene el inconveniente de ser un patrón que agrega bastante complejidad y que es poco legible debido a su “extraña” sintaxis. Así, si tuviésemos un AST y quisiésemos volverlo código mediante un visitor, nuestro código se vería así:

Pero si tratamos de seguir este código, y vamos directamente a la implementación de este método ‘Accept’ nos encontraremos con esto:

Y por último, si nos salteamos la abstracción IVisitor y vamos directamente a la implementación del método Visit del PrinterVisitor, nos encontramos con esto otro:

Si no conoces el patrón, posiblemente no comprendas este código (y tengamos en cuenta que nos hemos salteado las abstracciones!). Pero el motivo más frecuente por el que no se entiende, si es ese el caso, es porque es complejo.

Visitor alternativo

La propuesta que dejo no es mia, ni es nueva. Esta es una implementación muy popular en lenguajes dinámicos.

Partamos del mismo supuesto: tenemos un AST al que queremos transformar en un string. Lo primero que podemos cambiar es la sintaxis confuza del visitor clásico mediante el uso de un Extension Method, como sigue:

Ahora veamos cómo se ven los nodos de este árbol:

Si bien aquí tenemos una interface INode la cual no luce muy bien, la simplicidad de los nodos es evidente ya que no estamos forzando a implementar ningún método extraño, me refiero al método ‘Accept’. Peo vamos a ver la implementación:

Esta implementación es mucho menos compleja y legible, además de reducir notablemente el acoplamiento (los nodos no necesitan conocer al IVisitor ni implementar ningún método extra) lo que posibilita eliminar las referencias cíclicas.

Lucas Ontivero

C# Closures y tipos anónimos a la Javascript

Lucas Ontivero — Thu, 24 May 2012 05:13:28 GMT

Es C# realmente dinámico? Si hace Cuac es un pato, si hace lo mismo que un lenguaje dinámico es dinámico. Qué te dice este código:

Infraestructura

Lucas Ontivero — Tue, 17 Apr 2012 19:52:05 GMT

Por qué es necesario empujar tantos conceptos a la infaestructura como sea posible.

Patrón repetido en MVC. Mi propuesta

Lucas Ontivero — Wed, 08 Feb 2012 06:20:43 GMT

Cuando usamos ASP.MVC uno de los patrones que debemos respetar es el de “Un modelo entra, un modelo sale” y otro muy común es el de validar el modelo y si este no es válido devolverle la misma vista al usuario para que corrija los datos de entrada. Por esto es común ver el siguiente patrón:

¿Qué está mal aquí? ¿Lo ves?

Lo que está mal es que este patrón se repite en cada una de las acciones de cada uno de los controladores de cada una de las aplicaciones que hacemos con MVC Framework y eso huele muy pero muy mal (DRY).

Este es el tipo de casos en los que puede ayudarnos AOP, y MVC framework hace un trabajo espectacular al posibilitarnos implementar AOP mediante filtros. Entonces mi idea es que esto debería hacerse así:

Ahora sí el método hace lo que tiene que hacer, ni más ni menos. Para esto (y solo para demostrar mi punto) he creado el atributo ModelValidationAttribute (necesita un mejor nombre!) como sigue:

Y esto funciona a la perfección! Ojo, no recomiendo usarlo sin antes hacer una buena implementación ya que le faltan cosas al ViewResult como TempData entre otras (y el OnActionExecuted vacio tiene un olorcito medio feo – pero no es culpa mia! ¿por qué el creador de la interface IActionFilter me obliga a incumplir el contrato? ¿No serán 2 interfaces distintas [LSP]?)

Bueno, esto como les dije funciona a la perfección. La prueba:

Saludos.

Refactoring–Extract Method para separar validaciones de operaciones

Lucas Ontivero — Wed, 25 Jan 2012 19:55:59 GMT

Existen casos en los que es conveniente extraer un bloque de código en un nuevo método por razones de validaciones de entrada. Es decir, queremos sepaar el código de validaciones de entradas del código que realiza propiamente las operaciones con estas. En algunos casos esto además puede traernos algunos beneficios de performance. Esto es más claro en los métodos recursivos. Para ilustrar esto pongamos como ejemplo al clásico método que calcula el Factorial de N de manera recursiva:

Aquí el problema está en que el parámetro ‘n’ se valida en cada llamada pero la realidad es que esto no debería ser así ya que si ‘n’ es válido en la primera llamada este va a serlo también en todas las sucesivas invocaciones que se hacen de manera recursiva. Por este motivo es conveniente separar las validaciones y extraer el cálculo del factorial para llevarlo a otro método como sigue:

No es la performance lo que interesa aquí sino la separación conceptual de las validaciones y las operaciones, el incremento de la performance es solo un producto derivado de haber hecho esto.

[Video] Serie sobre excepciones–El rol de las interfaces

Lucas Ontivero — Tue, 24 Jan 2012 04:19:13 GMT

Esta es seguramente la última entrada sobre excepciones en la que explico el rol de la interfaces (con el usuario u otro tipo de clientes) en la captura, tratamiento y traducción de las excepciones.

[Video] Serie sobre excepciones – Explicando ejemplo del MSDN

Lucas Ontivero — Fri, 20 Jan 2012 06:00:07 GMT

En este video explico el por qué un ejemplo tomado del MSDN está mal y cómo debería de escribirse en cuanto a la manera en que trata las excepciones.

Excepciones – Un caso sobre los ejemplos del MSDN

Lucas Ontivero — Fri, 20 Jan 2012 05:25:31 GMT

Soy un convencido de que muchos de los malentendidos que existen en cuanto al manejo de excepciones en VB.Net y C# es por culpa de los malos ejemplos que siempre ha tenido el MSDN. Con solo invertir un par de segundos en google uno puede encontrar verdaderas aberraciones.. A modo de ejemplo solo pondré dos links y las capturas:

http://msdn.microsoft.com/en-us/library/system.net.dns.resolve(v=vs.110).aspx
Si Bien es cierto que los ejemplos han mejorado muchísimo, porque años antes eran un desastre, todavía siguen existiendo demasiados de estos ejemplos, ejemplos que son tomados por muchos desarrolladores como “bunas prácticas” ya que provienen de un sitio de la más alta confianza.

Otro ejemplo: http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient(v=vs.110).aspx. Hay tantas cosas mal en este que da para pensar si estos ejemplos ayudan a los programadores o si por el contrario, los perjudica.

[Video] Serie sobre excepciones–Donde capturarlas

Lucas Ontivero — Tue, 20 Dec 2011 01:47:03 GMT

Les dejo la tercera entrega de la serie sobre excepciones.

Saludos

Retoques a MVC y Razor para proyectos grandes–Una recomendación

Lucas Ontivero — Sat, 17 Dec 2011 22:28:32 GMT

Luego de revisar los requerimientos de la aplicación en la que vengo trabajado estos últimos 6 meses, tuve que pensar cómo plantear la arquitectura de la misma teniendo en cuenta lo siguiente:

La aplicación es muy muy muy grande, eso era lo primero que saltaba a la vista en los requerimientos. Al día de hoy, esta cuenta con 1.119 vistas, 797 controladores y un número similar de modelos, entre otras cosas.
El equipo iba a ser grande y la idea era que trabajaran lo más focalizados posible en sus casos de uso y luego integrarlos para evitar fricción de dependencias entre los diferentes casos de uso.
La aplicación tiene módulos que agrupan sub-módulos y estos a su vez agrupan casos de uso. Los casos de uso eran bastante similares por lo que era también de esperarse que tuviesen una estructura similar entre ellos. Esto es: Vistas con idénticos o similares nombres como así también controladores y modelos similares los cuales podían también tener el mismo nombre.
El esquema de seguridad se basa en perfiles de usuarios los cuales tienen permisos sobre distintas operaciones sobre cada uno de esos casos de uso.

Con eso en mente, era evidente que el esquema por defecto de MVC (usando Razor) no era el adecuado ya que, por defecto, este agrupa las vistas en la carpeta Views, controladores en la carpeta Controllers y modelos en la carpeta Models. Es muy difícil de trabajar en un sistema grande con esta estructura; es a todas luces insuficiente ya tener 1.119 vistas en una sola carpeta presenta muchos problemas no solo a la hora de encontrar un archivo sino que además obliga a que no existan dos vista con el mismo nombre y eso era algo que el proyecto necesitaba tener realmente.

De no plantear una estructura de módulos, sub-módulos y casos de uso adecuada a las necesidades del proyecto este iba a ser un desastre, así que así lo hice. Para esto extendí dos componentes: ControllerFactory y RazorViewEngine.

Antes de comenzar, y para que vayan dándose una idea, nuestro esquema de mapeo en el Global.asax es el siguiente:

Y nuestra estructura de carpetas es la que sigue:

El ControllerFactory (simplificado para este blog) se ve más o menos como figura abajo y nos permite tener clases controladores con el mismo nombre pero con distinto namespace:

Por otro lado, la organización de las vistas en carpetas módulo/sub-módulo/casodeuso/ se logró extendiendo la clase RazorViewEngine que es la encargada de resolver la ruta donde se deben buscar las vistas cuando desde un controllador se lo solicita. El código de la clase puede verse abajo:

Con esto no solo se logra que las vistas se busques en la carpeta propia del caso de uso al cual pertenecen sino que además el orden de búsqueda permite que si una vista, layout o template (EditorTemplate o DisplayTemplate) no se encuentra localmente en la carpeta del caso de uso, este busca luego en las vistas del sub-módulo y luego en las vistas del módulo.

Conclusión

Dado que ni el ControllerFactory del framework de MVC permite tener controladores con el mismo nombre ni que el esquema de carpetas que por defecto que utiliza RazorViewEngine es suficiente para proyectos realmente grandes, creo que todo proyecto necesita contemplar la conveniencia de, antes de comenzar a desarrollar sus casos de uso, estudiar esta o alguna otra alternativa.

Yo recomiendo esta solución fuertemente ya que viene dándonos excelentes resultados día tras día y nos ha vuelto la vida increíblemente más sencilla.

[Video] Serie sobre excepciones–Malas Prácticas

Lucas Ontivero — Fri, 16 Dec 2011 22:50:33 GMT

Les dejo la segunda entrega de la serie que estoy desarrollando para el equipo de desarrollo en el cual trabajo.

Saludos

[Video] Serie sobre excepciones–Exceptions vs ErrorCodes

Lucas Ontivero — Fri, 16 Dec 2011 22:47:42 GMT

Les dejo el primero de una serie de videos sobre excepciones que estoy creando para el equipo de desarrollo al que pertenezco. Espero les guste.

Saludos

[Patterns] UnitOfWork

Lucas Ontivero — Wed, 17 Aug 2011 05:13:21 GMT

Leyendo el artículo de Javier Torrecilla Patrón Unit of Work (UoW) o Unidad de Trabajo me acordé que en 2007 había escrito sobre este patrón y quiero rescatarlo aquí:

Este es uno de los patrones más útiles (desde mi punto de vista) con que me he encontrado en el libro "Patterns of Enterprise Application Architecture" (P of EAA) de Martin Fowler. Como dice Martin en su libro este patrón:

"Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."

Este patrón se utiliza entonces para trabajar con un conjunto de objetos persistentes que deben tratarse como una "unidad" de trabajo, almacenándose en una base de datos de manera atómica. Este patrón es el encargado de hacer el seguimiento de todos aquellos objetos que son nuevos, y que por lo tanto deben persistirse, todos los objetos que han sido modificados y que deben actualizarse en la base de datos y todos los que han sido borrados y deben quitarse de la base de datos.

Mediante la implementación del patrón UnitOfWork, se logra una disminución de la cantidad de idas y vueltas hacia la base de datos ya que los cambios se realizan por lotes (o unidades de trabajo) redundando en incremento en el rendimiento del sistema porque muchas veces el cuello de botella de las aplicaciones se encuentra en la red de datos. Otro aspecto interesante es que posibilita el esquema de trabajo desconectado con bloqueos optimistas sobre la base de datos, es decir, no se mantienen bloqueados los registros por largos períodos de tiempo sino que se abre una conexión, se inicia una transacción, se hacen los cambios, se hace commit y se libera la conexión todo esto en muy pero muy poco tiempo.

De ser necesaria la incorporación de un control de concurrencia sobre los registros que serán afectados durante la transacción, de modo de mantener la consistencia de los datos, este patrón nos brinda el ámbito adecuado en donde implementarlo.

Veamos un caso concreto, el famoso ejemplo de la factura. Existe una factura que el usuario debe modificar, entonces traemos desde la base de datos la factura con sus ítems (de factura) cargados, luego, una vez que lo presentamos en pantalla, el usuario hace lo siguiente:

Agrega dos ítems más a la lista de ítems,
Modifica el importe y/o la cantidad de productos de uno de los ítems y finalmente,
Elimina algún que otro ítem.

En este caso, cuando deben persistirse los datos? apenas agrega, modifica o elimina un ítem? o debe tratarse a la factura como una unidad y persistir todo junto? Si algo falla,... debe guardarse el resto? que sucede si otro usuario (además del que estamos hablando) estaba trabajando con el mismo documento al mismo tiempo pero guardó primero? como sabemos que fue lo que modificó el usuario y que, por lo tanto, debemos guardar? guardamos primero la factura y luego sus ítems o al revés?

Todas las respuestas a estas preguntas (que considero que las fuiste contestando) se resuelven mediante la implementación de este patrón.

Voy a explicarlo un poco. El Unit Of Work, como se observa en la figura de arriba, se implementa mediante una única clase la cual tendrá al menos tres listas, una lista para los objetos nuevos que deben guardarse en la db, otra lista para los objetos que han sido modificados y que por lo tanto deben modificarse en la db y, otra lista para los objetos que deben eliminarse. Opcionalmente, o mejor dicho, según la implementación lo requiera, puede contener una cuarta lista para almacenar clones de los objetos que se traen desde la base de datos, de manera que antes de persistir un objeto pueda corroborar, mediante estos clones de los objetos originales, que los registros correspondientes no han sido modificados por otro usuario.

Una razón para leer el libro y no solo conformarse con este artículo es que Fowler hace un análisis exhaustivo de este patrón (y de todos sus patrones), sus formas de implementar, cuando implementarlos, pros y contras y sobre todo, lo que a mi más me gustó fueron los distintos intentos por hacer esta clase lo más transparente posible para el programador. Así, por ejemplo, analiza la posibilidad de que todas las clases persistibles hereden de una clase base que automáticamente las registre como nuevas en el contenedor, que cuando se invoque el setter de una propiedad, esta notifique al UnitOfWork correspondiente para que la registre como dirty, etc.

Acá dejo una implementación sencillísima de UnitOfWork sin control de concurrencias y en colaboración con un DataMapper trivial (actualización: el artículo original tenía un proyecto adjunto el cual he perdido, por esta razón el DataMapper no está presente pero lo que originalmente hacía era retornar la sentencia sql necesaria para insertar, modificar y borrar los objetos en la base de datos).

using System;
using System.Collections.Generic;
using System.Text;
using System.Transactions;
using System.Data.SqlClient;
using System.Configuration;
using System.Threading;
using System.Resources;
using ConsoleApplication7;

namespace Patterns
{
    // Nuestra clase UnitOfWork (Martin Fowler)
    public class UnitOfWork
    {
        // Aquí estan las tres listas de las que hablamos
        // Ademas de estas puede existir una cuarta que almacene
        // los objetos limpios (o que se leyeron de la db)
        List<IBusinessObject> newObjects;
        List<IBusinessObject> dirtyObjects;
        List<IBusinessObject> removedObjects;

        // Creamos las listas en este constructor
        public UnitOfWork()
        {
            newObjects = new List<IBusinessObject>();
            dirtyObjects = new List<IBusinessObject>();
            removedObjects = new List<IBusinessObject>();
        }

        public void New(IBusinessObject bo)
        {
            Guard.NotNull(Resources.parameter_is_null, "bo", bo);
            Guard.IsTrue(Resources.object_is_dirty, dirtyObjects.Contains(bo));
            Guard.IsTrue(Resources.object_is_deleted, removedObjects.Contains(bo));
            Guard.IsTrue(Resources.object_is_already_inserted, newObjects.Contains(bo));

            newObjects.Add(bo);
        }

        public void Remove(IBusinessObject bo)
        {
            Guard.NotNull(Resources.parameter_is_null, "bo", bo);
            if (newObjects.Remove(bo)) return;
            dirtyObjects.Remove(bo);

            if (!removedObjects.Contains(bo))
                removedObjects.Add(bo);
        }

        public void Update(IBusinessObject bo)
        {
            Guard.NotNull(Resources.parameter_is_null, "bo", bo);
            Guard.IsTrue(Resources.object_is_deleted, removedObjects.Contains(bo));

            if (!newObjects.Contains(bo) && !dirtyObjects.Contains(bo))
                dirtyObjects.Add(bo);
        }

        // El método Commit es el encargado de iniciar las transacciones,
        // y realizar la invocación a la base de datos.
        public void Commit()
        {
            string connectString = string.Empty;
            using (TransactionScope transactionScope = new TransactionScope())
            {
                connectString = ConfigurationManager.ConnectionStrings["Patterns"].ConnectionString;

                using (SqlConnection connection = new SqlConnection(connectString))
                {
                    // Construimos las sentencias SQL para luego pasárselas a la DB
                    // mediante un command. Para esto, en .Net hay que hacerlo separando
                    // las sentencias con un punto y como (;)
                    StringBuilder stringBuilder = new StringBuilder();

                    foreach (IBusinessObject bo in newObjects)
                        stringBuilder.Append(Mapper.Instance.Insert(bo) + ";");

                    foreach (IBusinessObject bo in dirtyObjects)
                        stringBuilder.Append(Mapper.Instance.Update(bo) + ";");

                    foreach (IBusinessObject bo in removedObjects)
                        stringBuilder.Append(Mapper.Instance.Delete(bo) + ";");

                    string command = stringBuilder.ToString();

                    // Abre la conexió, crea el comando con las sentencias SQL
                    // e invoca al RDBMS.
                    connection.Open();
                    SqlCommand command1 = new SqlCommand(command, connection);
                    command1.ExecuteNonQuery();

                    // Limpia las listas si todo estuvo bien.
                    ClearAll();
                }
                transactionScope.Complete();
            }
        }

        private void ClearAll()
        {
            newObjects.Clear();
            dirtyObjects.Clear();
            removedObjects.Clear();
        }
    }
}

¿Lo que huele mal es la inyección de dependencias?

Lucas Ontivero — Fri, 15 Apr 2011 19:09:32 GMT

En mi anterior entrada mostraba distintas alternativas que podíamos utilizar para volver al siguiente fragmento de código fácilmente testeable. Obviamente existe una infinidad de alternativas que no he abordado como los frameworks de aislamiento, los servidores de smtp que no envían los mails y muchas más.

La idea aquí es mostrar el por qué este código no es un duro de testear. Obviamente es porque tiene una dependencia con la clase SmtpClient la cual se comunica mediante un socket con el ambiente externo.

Entonces, el problema radica en la sentencia:

Ahora bien, en algunos lenguajes como por ejemplo, Ruby. El mismo código es fácilmente testeable ya que las clases e incluso las instancias están abiertas para la modificación en tiempo de ejecución. Entonces en Ruby podemos sobre escribir el método “new” de manera que nos devuelva un tipo diferente al que le pedimos. ¿Podemos en C# hacer lo mismo? Ummm…. la respuesta correcta es no, pero podemos acercarnos bastante. Fijate si notas la diferencia entre el siguiente código y el primero:

¿La encontraste? Bien! Este código ahora si es testeable. De la siguiente manera:

A simple vista se parece mucho a una sobrecarga del operador “new”, también podría compararse con un contenedor de inversión de control o con una factoría. No es mi intención discutir ese tema sino mostrar como las características nuevas de c# 4 sobre el mundo dinámico nos puede ayudar a pensar en otros tipos de soluciones.

Les dejo todo el código (es solo una prueba de concepto):

using System;

using System.Collections.Generic;

using System.Net.Mail;

namespace CSharpDi

    public class Program

        public static void Main()

            typeof(SmtpClient).RegisterBuilder(p =>

new

                    Send = new Action<string, string, string, string>(

                    (from, to, subject, body) => { })

);

            var tm = new TranferManager();

            tm.Tranfer();

    public class TranferManager

        public void Tranfer()

            // Perform the required actions

            var smtpClient = New. SmtpClient();

            smtpClient.Send("info@bank.com", "from.Email", "Tranfer", "?");

    public static class New

        public static dynamic SmtpClient(params object[] parameters)

            return typeof(SmtpClient).New(parameters);

    public static class CreationExtensions

        private static Dictionary<Type, Func<object, dynamic>> builders =

            new Dictionary<Type, Func<object, dynamic>>();

        public static dynamic New(this Type type, params object[] parameters)

            if(builders.ContainsKey(type))

                return builders[type](parameters);

            return Activator.CreateInstance(type, parameters);

        public static void RegisterBuilder(this Type type, Func<object, dynamic> builder)

            builders.Add(type, builder);

¿Como vuelvo testeable mi código? Algo huele mal.

Lucas Ontivero — Fri, 15 Apr 2011 12:07:00 GMT

Veamos el siguiente código:

Lo que buscamos crear al menos una prueba unitaria para este. ¿Cómo lo hacemos?. Bueno, antes quiero plantear algunos supuestos:

Si bien parece un TransactionScript, hagamos de cuenta que no lo es. El hecho de tener solo un método y ningún campo, propiedad o evento es solo para hacer de este un ejemplo ultra sencillo. Por lo tanto pensemos que sí tiene campos, propiedades y varios métodos.
Si bien usamos un System.Net.Mail.SmtpClient, la idea es no limitarse solo a esta clase sino que puede ser cualquier otra (en este caso una clase de la BCL). Quizás no tenemos el código para modificarlo (como en este caso) o quizás sí lo tenemos pero modificarlo no es buena idea.
En principio solo queremos verificar que la transferencia se realiza y NO que el mail se envía correctamente.

Las opciones que analizaremos aquí son:

Inyección de dependencias (DI)
Sub clasificación
Decoración

Inyección de dependencias

Usar un Gateway es uno de los caminos más habituales que podemos encontrar para “volver testeable nuestro código”. Hacer esto con el único objetivo de testear el código para mí no solo que no vale la pena sino que es incorrecto. Es una sobre ingeniería, a pequeña escala en este caso, y un despropósito puesto que difícilmente tendremos en el futuro otro tipo de cliente de mail. El único cliente de mail extra existe solo con motivo de testing. Y además tenemos 2 constructores, una interface y una clase extra, etc, etc… horrible. ¡Si tan solo el método Send del SmtpClient fuese virtual!

Si no quisiéramos pagar ese costo, ahorrarnos la interface y la clase extra pero seguir utilizando la DI como mecanismo, lo que podríamos hacer es darnos una vuelta por el mundo dinámico. Básicamente, cualquier tipo que responda a “Send(string, string, string, string)” nos va a servir.

Las dos principales objeciones a esta alternativa vienen de parte de aquellos a quienes les disgustan (¿o asustan?) las implicaciones del chequeo de tipos en tiempo de ejecución como de aquellos a quienes les disgusta el inyectar este tipo de dependencias. Por lo demás, esto facilita bastante la creación de las pruebas. Abajo hay dos pruebas que usan tipos anónimos para realizar dos tipos de pruebas distintas.

Una solución intermedia entre inyectar tipos estáticos y dinámicos es inyectar acciones. Es decir, inyectar la pieza de código que queremos que se ejecute para enviar los mails como vemos abajo. Esto también facilita enormemente la creación de pruebas y si bien es aceptable, tiene, además del mismo mal olor de todas las alternativas que requieren inyectar dependencias, el problema de ser poco intuitiva. Veamos un ejemplo:

Conclusión parcial: la inyección de dependencias, en cualquiera de sus formas, nos puede ayudar a crear código más testeable aunque requiere de cierto código extra y ciertos patrones que no siempre redundan en mejor código. Por esta razón, la DI, en casos similares a los de los ejemplos que he presentado, no es una buena alternativa.

Sub clasificación

Uno podría argumentar que quizás nuestro método Tranfer necesita una pequeña refactorización la cual nos podría ayudar a mejorar el código y de pasada, hacerlo más testeable… veamos:

Ahora podemos crear versiones testeables de esta clase, ya sea a mano o utilizando algún framework de aislamiento.

Esto parece algo más limpio ¿verdad? No necesitamos extrañas interfaces, constructores, tipos dinámicos ni nada de lo que vimos con anterioridad. Una objeción: ¿qué sucede si la clase necesita ser sealed? Este punto de extensión ha sido creado nuevamente con el único propósito de posibilitar las pruebas porque de lo contrario, el método no sería protected virtual sino simplemente private. Ok, pero es una alternativa válida y nos sirve.

Decoración

Quizás la responsabilidad de enviar las notificaciones no sea algo propio de nuestra clase TranferManager y por lo tanto podríamos sacar esa responsabilidad a otra clase usando el patrón decorador (o podríamos usar un wrapper también). Veamos:

Ahora podemos testear TranferManager sin dificultades. El problema que se nos presenta ahora es que tal vez lo que necesitamos testear ahora sea la nueva clase TranferManagerWithNotification.

Esta entrada se ha vuelto muy extensa así que la continuaré más adelante…

¿Vale la pena crear pruebas unitarias?

Lucas Ontivero — Thu, 31 Mar 2011 16:19:43 GMT

La creación de pruebas unitarias requiere al menos lo siguiente:

Un framework de pruebas unitarias que debemos dominar. Por lo general son muy simples.
Código testeable. Típicamente esto implica código susceptible de ser “aislado”.

Nada que decir con respecto al primer punto. Ahora, en cuanto al segundo punto, ¿qué significa que el código pueda ser “aislado”?. Bueno, esto significa que sus dependencias deben poder ser reemplazadas. Esto lo logramos bien por medio de inyectarle sus dependencias o bien utilizando un patrón ServiceLocator (a algún framework con un contenedor de dependencias).

Entonces, una vez resuelto, necesitamos proveer al código objeto de prueba, dependencias “falsas”. Esto nuevamente requiere o bien que las creemos a manos o que utilicemos algún isolation framework para crearlas (por lo general en runtime).

Hasta ahora nada que no sepamos todos ¿verdad? Pero… ¡Vamos de nuevo! Veámoslo en código por favor. Imaginemos que tenemos el siguiente método pero no podemos probarlo porque su dependencia con el LogHelper (una clase con métodos estáticos) nos lo impiden:

     public class TransferManager

    {

        public void Tranfer(Account from, Account to, Money amount)

        {

            // Perform the required actions

            LogHelper.Inform("Done!");

        }

    }

Si no quisiéramos enredarnos mucho, lo que haríamos sería algo como lo que sigue:

    public class TransferManager

    {

        private readonly ILogger _logger;

        public TransferManager(ILogger logger)

        {

            this._logger = logger;

        }

        public void Tranfer(Account from, Account to, Money amount)

        {

            // Perform the required actions

            _logger.Inform("Done!");

        }

    }

Y la prueba, se parecería a lo que sigue:

    [TestMethod]

    public void Perform_a_valid_tranfer()

    {

        var aFakeLogger = new FakeLogger();

        var tranferManager = new TransferManager(aFakeLogger);

        // Do and Assert here

    }

Lo que falta:

    interface ILogger

    {

        void Inform(string messageToLog);

    }

    class FakeLogger : ILogger

    {

        public void  Inform(string messageToLog)

        {

            // Nothing to do

        }

    }

¿Que debimos hacer para probar esa pieza de código? Bueno, varias cosas: en primer lugar fue necesario crear una interface hasta el momento innecesaria (ILogger), tuvimos que agregar un constructor para inyectarle esta dependencia juntamente con un campo para almacenarla; debimos además, y aunque no se muestre aquí, hacer un wrapper para el LogHelper que implemente la interface ILogger. Por otro lado, en el proyecto de prueba, debimos crear una clase falsa (la FakeLogger).

Creamos FakeLogger de manera manual y con su implementación más sencilla (no hace absolutamente nada) pero bien podríamos haberla creado con un framework de aislamiento y especificarle algún comportamiento.

Es decir que el código es ahora más complejo que antes ya que tiene, al menos en este ejemplo, un campo más (_logger), un constructor más, una interface más (la ILogger) y una clase más (el wrapper del LogHelper). El código que crea una instancia de esta clase (TranferManager) también se ve afectado. Este es el costo que lleva asociado ineludiblemente el probar, mediante pruebas unitarias, cualquier código.

Claro, la pregunta es: ¿Valdrá la pena?

Compiler as a Service – Parte 2

Lucas Ontivero — Tue, 22 Feb 2011 18:34:46 GMT

Si el compilador de C# pudiera utilizarse como cualquier assembly, podríamos generar código y compilarlo en tiempo de ejecución. Con esto, muchas de las cosas que hoy hacemos mediante CodeDom o Expression trees, las podríamos hacer simplemente concatenando strings (hay maneras mejores).

Por ejemplo, imaginemos un framework para crear clases Mock al que llamaremos RinhaMock. Aplicaremos este framework en el siguiente test unitario:

   1: [TestClass]

   2: public class Tests

   3: {

   4:     public void It_should_send_messages_with_values()

   5:     {

   6:         var sentMessage = string.Empty;

7:

   8:         dynamic sender = RinhaMock.Stub<IMessageSender>();

   9:         sender.When_Send_String = new Action<string>(s => sentMessage = s);

10:

  11:         var transacionManager = new TransactionManager(sender);

  12:         transacionManager.Deposit(amount: 50m, accountNo: "0087623481743", concept: "Pago cuota");

13:

  14:         Assert.AreEqual("50;0087623481743;Pago cuota", sentMessage);

  15:     }

  16: }

La idea es crear dinámicamente un tipo que implemente la interface IMessageSender y cuyo comportamiento pueda ser especificado fácilmente. Para que el ejemplo sea bien sencillo, vamos a tener una interface IMessageSender con solo un método y una clase TransactionManager igualmente simple:

   1: public interface IMessageSender

   2: {

   3:     void Send(string message);

   4: }

5:

   6: public class TransactionManager

   7: {

   8:     private IMessageSender _messageSender;

9:

  10:     public TransactionManager(IMessageSender messageSender)

  11:     {

  12:         this._messageSender = messageSender;

  13:     }

14:

  15:     internal void Deposit(decimal amount, string accountNo, string concept)

  16:     {

  17:         // Do the deposit here

  18:         var message = string.Format("{0};{1};{2}", amount, accountNo,concept);

  19:         _messageSender.Send(message);

  20:     }

  21: }

Ahora, la clase stub podría ser escrita por nuestras propias manos, como abajo:

   1: public class Stub__IMessageSender : CSharp5.IMessageSender

   2: {

   3:     public Action<System.String> When_Send_String { get; set; }

   4:     public void Send ( System.String message )

   5:     {

   6:         When_Send_String(message);

   7:     }

   8: }

O bien se podría creada a partir de la metadata de la interface IMessageSender y compilada en tiempo de ejecución. Esta última opción, que hoy tenemos con CodeDom, podría ser mucho más rápida y sencilla si el compilador de C# estuviera disponible como un assembly.

El código necesario para crear el código de la clase stub es el siguiente:

   1: public class RinhaMock

   2: {

   3:     public static T Stub<T>() where T : class

   4:     {

   5:         var typeOfT = typeof(T);

   6:         string stubName = "Stub__" + typeOfT.Name;

   7:         var sb = new StringBuilder();

8:

   9:         var methods = typeOfT

  10:             .GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.InvokeMethod)

  11:             .Where(m => (m.IsVirtual || m.IsAbstract) && !m.IsSpecialName && !m.IsFinal);

  12:         methods.ForEach(m => sb.AppendLine(GetConfigPropertyCode(m)));

  13:         methods.ForEach(m => sb.AppendLine(GetMethodCode(m)));

14:

  15:         var scripRunner = new ScriptRunner(typeOfT);

  16:         var results = new Dictionary<string, object>();

  17:         scripRunner.AddObject<Dictionary<string, object>>("results", results);

  18:         scripRunner.AddUsing("CSharp5");

  19:         scripRunner.AddTypeCode(string.Format("public class {0} : {1} {{ {2} }}", stubName, typeOfT.FullName, sb.ToString()));

  20:         scripRunner.AddCode("results[\"stub\"] = new " + stubName + "();");

  21:         scripRunner.Run();

22:

  23:         return (T)results["stub"];

  24:     }

25:

  26:     private static string GetMethodCode(MethodInfo method)

  27:     {

  28:         var isProcedure = method.ReturnType == typeof(void);

  29:         var parameters = method.GetParameters();

30:

  31:         return string.Format("public {6} {0} {1} ( {2} ) {{ {3} When_{1}{5}({4}); }}",

  32:             isProcedure ? "void" : method.ReturnType.FullName,

  33:             method.Name,

  34:             parameters.Select(p => string.Concat(p.ParameterType.FullName, " ", p.Name)).ToStringList(),

  35:             isProcedure ? string.Empty : "return",

  36:             parameters.Select(p => p.Name).ToStringList(),

  37:             parameters.Any()

  38:                 ? "_" + parameters.Select(p => p.ParameterType.Name.Replace("[]", "Array")).ToStringList("_")

  39:                 : string.Empty,

  40:             method.DeclaringType.IsInterface ? "" : "override"

  41:             );

  42:     }

43:

  44:     private static string GetConfigPropertyCode(MethodInfo method)

  45:     {

  46:         var isProcedure = method.ReturnType == typeof(void);

  47:         var parameters = method.GetParameters();

48:

  49:         var methodReturnedType = isProcedure ? "void" : method.ReturnType.FullName;

  50:         var parametersType = parameters.Select(p => p.ParameterType);

  51:         var returnedSign = isProcedure ? "Action<{0}>" :

  52:             string.Format("Func<{0}{1}>", "{0}", (parametersType.Any() ? "," : "") + methodReturnedType);

  53:         var parametersForSign = parametersType.Select(t => t.Name.Replace("[]", "Array")).ToStringList("_");

54:

  55:         return string.Format("public {0} When_{1}{2} {{ get; set; }}",

  56:             isProcedure && !parameters.Any()

  57:                 ? "Action"

  58:                 : string.Format(returnedSign, parametersType.Select(t => t.FullName).ToStringList()),

  59:             method.Name,

  60:             parametersType.Any() ? "_" + parametersForSign : string.Empty);

  61:     }

  62: }

63:

  64: static class StringListExtensions

  65: {

  66:     public static string ToStringList(this IEnumerable<string> enumerable, string separator = ", ")

  67:     {

  68:         if (!enumerable.Any())

  69:             return string.Empty;

70:

  71:         return enumerable.Aggregate((s1, s2) => string.Concat(s1, separator, s2));

  72:     }

  73: }

74:

  75: static class IEnumerableExtensions

  76: {

  77:     public static void ForEach<T>(this IEnumerable<T> enumerable, Action<T> action)

  78:     {

  79:         foreach (var t in enumerable) action(t);

  80:     }

  81: }

Como se puede ver, esta podría ser una alternativa viable a todos esos frameworks para la creación de clases proxies como Castle.DynamicProxy (usado por RhinoMocks).

Compiler as a Service – Parte 1

Lucas Ontivero — Tue, 22 Feb 2011 15:31:55 GMT

Pensaba acerca de las cosas que podríamos hacer si el compilador de C# fuese un assembly reutilizable (Compilar as a service). Lo primero, y menos original, que se me ocurrió es que podríamos tener algo como JSON pero para C# en lugar de Java Script.

   1: class Program

   2: {

   3:     static void Main(string[] args)

   4:     {

   5:         const string data = @"results[""professional""] =

   6:         new

   7:         {

   8:             FirstName = ""Juan Pablo"",

   9:             LastName = ""Ibañez"",

  10:             Certifications = new[]

  11:             {

  12:                 new { Provider=""MSFT"", ExamCode = ""70-536"", Title = ""Application Development Foundation"" },

  13:                 new { Provider=""MSFT"", ExamCode = ""70-505"", Title = ""Application Development Foundation"" },

  14:                 new { Provider=""MSFT"", ExamCode = ""70-563"", Title = ""Application Development Foundation"" }

  15:             },

16:

  17:             SayHi = new System.Action(()=> System.Console.WriteLine(""Hi""))

  18:         };";

19:

  20:         dynamic professional = CSharpEvaluator.Evaluate(data)["professional"];

21:

  22:         Console.WriteLine("First Name: {0}", professional.FirstName);

  23:         Console.WriteLine("Last Name : {0}", professional.LastName);

  24:         foreach (var certification in professional.Certifications)

  25:         {

  26:             Console.WriteLine("\tCertification: {0}", certification.Title);

  27:         }

  28:         professional.SayHi();

  29:     }

  30: }

Esto abriría realmente muchas posibilidades. Una de las que me atrae más es el sustituir los XMLs. Quizás para guardarlos en una base de datos como entidades completas y hacerlas viajar por la red.

Otro ejemplo de DSL en el mundo real

Lucas Ontivero — Fri, 27 Aug 2010 03:31:44 GMT

Desarrollo un sistema para la planificación, ejecución y seguimiento de encuestas en el que uno de los requerimientos es poder crear encuestas de manera sencilla y veloz. Además las mismas deben seguir un workflow (algo informal) de revisión. Otro dato importante es que el cliente diseña encuestas que van desde aquellas con solo algunas pocas preguntas hasta esas otras que nos tienen todo un domingo respondiendo acerca de alguna ginebra o algún nuevo centro comercial. Para rematar debo decir que...(read more)

Cómo afectan los Mock frameworks nuestras pruebas unitarias

Lucas Ontivero — Sat, 21 Aug 2010 20:24:41 GMT

Una de las características más importante que debe seguir cualquier código y que es particularmente importante en las pruebas de cualquier tipo es la claridad. Una prueba debe entenderse a la primera sin demasiado esfuerzo, por eso es que debe ser breve, clara y desprovista en el mayor grado posible de elementos ‘ruidosos’. Uno de esos factores ruidosos son los frameworks de aislamiento, los mal llamados Mocking Frameworks. Es por esto que limitar su uso a aquellas ocasiones verdaderamente justificables...(read more)