Archivos mensuales: Abril 2011

¿Cuál es la diferencia entre el patrón strategy y state?

El jueves pasado estuvimos viendo temas de polimorfismo en el curso Elementos avanzados de arquitectura de software con objetos y, al cabo de un ejemplo, yo plantee que lo que habíamos visto era el patrón State. Hernán me puso cara de “no tanto” y sospecho que en próximas clases entenderé el porqué.

Sin embargo surgió un mini debate con unos de mis compañeros de curso: el argumentaba que en realidad lo que habíamos visto era el patrón Strategy. Creo que esta es una duda común porque ambos patrones son parecidos en algunos aspectos de la implementación y en el diagrama de clases pero son conceptualmente distintos, por lo tanto me pareció bueno escribir un pequeño post.

El patrón State permite hacer diferentes cosas dependiendo del estado del objeto. En otras palabras, lo que cambia de acuerdo al estado es que se hace. Además, todas las posibilidades están incluidas en el código del modelo. A la hora de agregar nuevos estados y su correspondiente acción asociada basta con agregar una subclase sin tocar las demás (observando el Open-Close principle).

En cambio el patrón Strategy permite hacer lo mismo de diferentes maneras. En otras palabras, lo que cambia es como se hace. Este patrón usualmente permite que la implementación específica (la estrategia) se pueda seleccionar por configuración, por el estado de cierto objeto, etc.

Les dejo algunos links en inglés que aportan mas detalles:

http://stackoverflow.com/questions/1658192/what-is-the-difference-between-strategy-design-pattern-and-state-design-pattern

http://www.c-sharpcorner.com/UploadFile/rmcochran/strategy_state01172007114905AM/strategy_state.aspx

http://c2.com/cgi/wiki?StrategyPattern

[PDF] http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf

Volviendo al preescolar en diseño orientado a objetos

Ayer comencé el curso Elementos avanzados de arquitectura de software con objetos de 10Pines, a cargo de Hernán Wilkinson (@HernanWilkinson).

Intentaré contar mis vivencias luego de cada una de las 6 clases, sin mucho análisis, en su versión cruda. Luego vendrá el tiempo de las conclusiones.

Antes de comenzar el curso estuve releyendo algún material relevante sobre diseño orientado a objetos (DOO), sobre todo el libro Smalltalk, Object and Desing, de Chamond Liu. Recomiendo este libro que, a pesar de su apariencia sencilla, no tiene desperdicio, una ganga por USD 24.

Vuelvo al curso. Es evidente que Hernán tiene mucha experiencia enseñando “objetos” ya que nos mantuvo interesados durante cuatro horas con tres simples conceptos: objetos, colaboración y mensajes, todo esto sin tocar las computadoras.

Lo primero que nos pidió fue que, momentáneamente, nos olvidáramos de todo lo que sabíamos de diseño orientado a objetos (DOO). Creo que es el enfoque apropiado para el curso ya que es usual que tengamos muchos conceptos mal aprendidos y eso dificultaría bastante el aprendizaje.

Aquellos con los que he hablado del tema sabrán que hace varios años hice mi “click” y comencé a dar el próximo paso en DOO, empezando a prestar mas atención al comportamiento en los objetos y menos al estado.

Ese fue el eje de la clase de ayer, el funcionamiento de cualquier programa consiste en objetos colaborando entre si mediante el envío de mensajes (“aproximadamente” métodos en Java o .NET). Cuales son esos objetos, cuales son esos mensajes forma parte de la tarea difícil del diseñador. Es ahí donde esta la fortaleza del diseño que hará que nuestro código sea fácil de mantener o una verdadera pesadilla.

Hernán destila Smalltalk por los poros y no tiene manera de disimularlo (y creo que tampoco quiere), personalmente valoro mucho esto porque nos permite aprender las técnicas en un entorno puro, ya habrá tiempo luego para “perder flexibilidad” en otras plataformas.

El próximo jueves o viernes la próxima entrega.

Nos vemos.