Presentando Patrones de Diseño (Design Patterns)

Como ya había anunciado, el sábado 16 de Octubre participé de una VAN de la comunidad ALT.NET Hispano, sobre Patrones de Diseño. En cualquier momento, la gente de ALT.NET Hispano publica el video de la VAN (Des-conferencia virtual). Mientras, les dejo acá la presentación DesignPatterns.pptx.

La idea fue presentar algunos patrones a través de un ejemplo. Usé para eso el patrón Interpreter: estuvimos explorando el código de un intérprete escrito en C#. Lo pueden bajar desde mi proyecto Google AjCodeKatas (en el directorio Patterns), donde posiblemente vaya evolucionando, o pueden tomar la versión actual desde Patterns20101017.zip (noten que los namespaces que usé fueron elegidos para describir patrones, más que para un intérprete real). El ejemplo fue desarrollado con TDD (Test-Driven Design), pero no vimos el proceso en la charla: vimos el resultado, directamente. Para los que quieran ver un intérprete desarrollado usando TDD pueden seguir mi serie de posts sobre el tema en el tag TDD ejemplo: Escribiendo un intérprete en .NET (Parte 7).

También mencionamos código de NHibernate, pero no llegamos a verlo. Comenté sobre Facade y Strategy usando una aplicación de demo generada con AjGenesis y que usa NHibernate. Pueden bajar la versión actual (work in progress) de AjTestNh20101017.zip.

Acá va una lista de los patrones que vimos, y el código elegido para ejemplicar cada uno:

Interpreter: con el intérprete de expresiones que escribí como base de la charla.

Composite: con comandos en el intérprete. Uno de los comandos contiene una lista de comandos.

Template Method: lo encontrarán en el método Evaluate de las BinaryExpressions: se evalúan dos expresiones, y el resultado final se calcula invocando al método .Apply, que es reimplementado en las subclases.

Strategy: En vez de escribir un objeto de una clase por Strategy, escribí Func<obj,obj,obj> a aplicar dentro de la evaluación de ArithmeticBinaryExpression.

Decorator: a cada comando y expresión del intérprete, se le pasa un IContext, que tiene la responsabilidad de mantener los valores de las variables que manejamos. Lo decoré para tener un IContext que avise con eventos qué variables y valores se consultan y modifican.

Observer: usé directamente eventos de .NET, que son una evolución de este tema.

Adapter: cuando quise consumir un archivo como TextReader, con código del lenguaje a interpretar, necesitaba leer, no líneas, sino palabras del lenguajes (clase Token). El Lexer del ejemplo es un adapter para eso.

Abstract Factory: acá me aparté del intérprete y usé una implementación que termina usando los providers de ADO.NET, que a su vez funcionan como Abstract Factory.

Facade: junto con Strategy, son los más importantes a aprender. Todo Strategy nos deriva a composición en lugar de herencia, y a Dependency Injection, Inversion of Control y contenedores. Como Facade mencioné la “API de Negocios” que ya había comentado en otra VAN, y mostré una capa fina de servicio lógico en la aplicación de NHibernate que mencioné más arriba.

No llegué a presentar Facade en el ejemplo intérprete, pero pueden ver la clase Machine, que termina usando por debajo a Parser (otra especie de Adapter), Lexer, archivos, y Context, sin que tengamos que manejar esos objetos desde “afuera”.

Y también encontrarán un ejemplo de Visitor, que toma un programa del intérprete y lo “decompila” a texto.

Tiene más ejemplos y los diagramas UML (que usé en la charla) en:

http://www.dofactory.com/Patterns/Patterns.aspx

Terminó la presentación y vino una discusión, muy interesante. Alguien de Guatemala (disculpen, no recuerdo el nombre) necesitaba trabajar en un caso: para un sistema, hay que calcular el precio de los productos, pero esas reglas cambian mucho en el tiempo y por producto. Surgieron ideas: poner una Factory que genere la Strategy a aplicar en cada caso, y hasta tener una Strategy que interprete código que se levante de un texto. Me hizo recordar a sistemas de sueldos y jornales que ví acá en Argentina. Ahí mencioné que pueden usar el ejemplo de:

Un ejemplo de Dynamic Expressions

donde se compila una expresión lambda escrita en texto. Ahí se mencionan otras alternativas.

Otro camino es usar AjSharp como intérprete, ver los posts de AjSharp Debería escribir un post sobre cómo resolver un tema parecido al planteado en la VAN. También pueden ver a AjSharp como un intérprete mucho más terminado que el ejemplo de la charla. Es parte de AjCodeKatas y pueden verlo aquí.

Otro camino (debo post sobre mi charla en el pasado CodeCamp de Buenos Aires, sobre Intérpretes y Compiladores en .NET), es usar Dynamic Language Runtime:

http://dlr.codeplex.com/

Y hay también facilidades en .NET para compilar “on the fly”, usando CodeDOM, Reflection.Emit, y el compilador de .NET. Pero eso pienso que sería un camino más duro. Escribiré sobre eso en el post que debo sobre mi charla en el CodeCamp.

Gracias a la comunidad ALT.NET Hispano y en especial, al flamante MVP @jorgegamba y también al bueno de @fabiomaulo que me acercó información de nuevos patrones, y a todos los que colaboran con la grabación, edición del video y la organización de todas estas actividades.

Ah! Y en cerca del principio del video, hay una sorpresa … ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10746, 10790, 12081, 1389, 3463. Bookmark the permalink.

One Response to Presentando Patrones de Diseño (Design Patterns)

  1. ignacio says:

    Que bueno! Lástima que olvide por completo que estaba la charla, pensaba “escapar” del crusado para esucharla.
    La proxima será.
    Saludos

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>