Lucas Ontivero : Refactoring

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.

Código libre de NULLs

Lucas Ontivero — Thu, 02 Feb 2012 20:02:23 GMT

En este video explico los problemas que causan las referencias nulas en nuestro código y planteo cómo debemos crear un código libre de NULLs.

Refactoring – Move switch to Table

Lucas Ontivero — Mon, 30 Jan 2012 16:57:00 GMT

Esta es quizás una de las técnicas más antiguas de programación pero como no lo he visto en el catalogo de refactoring me he decidido a ponerlo aquí. Esta técnica es llamada Table Driven Method en el libro de Steve McConnell (Code Complete) pero como ya dije, la técnica es mucho más antigua que el libro.

La idea es reemplazar código como este:

Por algo como lo que sigue:

Nota: es cierto que el comportamiento de ambos métodos es distinto pero es solo para mostrar la idea.

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.

.Net Reflector y ILSpy, ¿podrían inferir mejor el código a partir del IL?

Lucas Ontivero — Sat, 10 Dec 2011 06:33:00 GMT

Muchas veces uno cree que el código que .Net Reflector muestra es fiel reflejo de lo que el desarrollador escribió, pero obviamente eso no puede ser cierto ya que esta herramienta toma el IL de un ensamblado y trata de mostrar su equivalente en los lenguajes que se le pida (C#, VB.NET, F# entre otros). Claro que muchas veces hacen tan buen trabajo que uno se olvida de eso.

Como a ILSpy le falta una vueltita de rosca en este aspecto, esto se hace más evidente ya que uno termina viendo código menos pulido como instrucciones GOTOs y otras yerbas en el propio código que uno escribió. Ahora bien, ¿que sucede cuando uno escribe 2 métodos con distintas instrucciones de un lenguaje pero equivalentes en funcionamiento? ¿Pueden estas herramientas hacer un buen trabajo?

Para responder a esta pregunta escribí tres métodos que hacen exactamente lo mismo: imprimen 100 líneas en la consola con los números del 0 al 99:

Quería ver si .Net Reflector y ILSpy podían ver la diferencia y la respuesta es: NO, NO PUEDEN. La razón es obvia ya que los tres métodos generan exactamente el mismo código intermedio (IL):

Dado que los tres métodos son idénticos bit a bit, ninguna herramienta podría determinar si corresponden a una instrucción for, while o a un enredo de gotos. Tampoco podríamos inferir cual fue el lenguaje con que se escribieron estos métodos (aunque eso poco importa). No obstante, esta es la estructura típica de un bucle for y por lo eso es que tanto .Net Reflector como ILSpy, cuando se les pide que muestren el código C# equivalente, muestran el siguiente fragmento para los tres métodos:

Ahora bien, el código IL es idéntico cuando se lo compila en modo Release pero no así cuando se lo compila en modo Debug ya que en este último caso, entre cada instrucción del lenguaje (digamos C#) se coloca una instrucción nop para habilitarnos a poner puntos de interrupción en partes de nuestro código que no se traducen a IL (no son instrucciones ejecutables). Por ejemplo, gracias a estos nops es que podemos poner un breakpoint al inicio de un bloque en modo Debug pero no así en modo Release:

En modo Debug esto este breakpoint es válido mientras que en modo Release el depurador pone automáticamente el breakpoint en la primera línea ejecutable despues de la llave {.

Ahora bien, dado que cada compilador agrega distinto número de instrucciones nop (esto podría ser falso ya que no probé todos los compiladores, obvio!) a los ensamblados compilador en modo Debug, herramientas como .Net Reflector y ILSpy podrían determinar cual es el lenguaje (en realidad, cual es el compilador) con que se generó ese ensamblado y también saber que un mismo algoritmo originalmente se desarrolló a partir de distintos conjuntos de instrucciones. Veamos el IL de los tres métodos originales en Modo Debug:

Como se ve estos tres ahora son diferentes y son aún más diferentes si los compilamos en VB.Net por esto es que digo que sería posible que cuando un ensamblado ha sido compilado en modo debug, estas herramientas cuentan con más información para inferir el código original. Y ya sé que el mundo no es solo C# y VB.Net y que esto quizás no vale la pena, solo digo que si estas herramientas quieren mostrar el código equivalente al IL en algunos de estos lenguajes, y el ensamblado está compilado en modo debug (casi nunca lo está), entonces podrían usar esta info para mostrar el código más parecido al original.

¿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?

Como refactorizar métodos estáticos

Lucas Ontivero — Sat, 14 Aug 2010 03:43:29 GMT

Imagina que encontramos un clase estática con varios métodos estáticos los cuales tienen una cantidad aberrante de parámetros. Queremos eliminarla pero nos damos con que está siendo usada en muchísimas partes ¿que hacemos? ¿Como lo harias vos?. Para hablar más concretamente veamos uno de esos métodos: public static void CreateActivityLog( string containerSourceId, string containerId, string action, string sourceId, string instanceId, string docNo, string notes, IFrameworkSecurityContext credentials...(read more)