Antipatrones de desarrollo de software: The Blob

También conocido como The God Class.
La película The Blob es una buena analogía para este antipatrón. Si bien hay dos películas, una de 1958 y una remake de 1988, ambas tienen casi el mismo argumento: Una forma de vida extraterrestre con forma de gelatina ataca a la tierra. Cualquier cosa que este alien coma, lo hace crecer. MIentras tanto, los incrédulos terrícolas entran en pánico e ignoran al científico loco que es el único que sabe lo que está pasando. Mucha gente es comida antes de que ellos entren en razón. Eventualmente, the blob se hace tan grande que amenaza con acabar con todo el planeta.
Tal como este alienígena, el antipatrón es conocido por haberse "devorado" enteras arquitecturas orientadas a objetos.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones de desarrollo de software

Una buena estructura de software es esencial para la extensión y mantenimiento de un sistema. El desarrollo de software es una actividad caótica, por lo tanto, la estructura implementada de un sistema tiende a alejarse de la estructura planificada según la arquitectura, el análisis y el diseño.
El refactoring del software es un enfoque eficaz para mejorar su estructura. La estructura resultante no tiene que se parecida a la estructura originalmente planificada.
Los cambios de estructura debido a que los programadores aprenden limitaciones y enfoques, alteran el contexto de las soluciones codificadas. Cuando es usado apropiadamente, el refactoring es una actividad natural en el proceso de programación.
Por ejemplo, la solución para el Antipatrón Spaghetti Code define un proceso de desarrollo de software que incorpora refactoring. Este es altamente recomendable antes que la optimización de rendimiento. Las optimizaciones, a menudo, implican comprometer la estructura del programa. Idealmente, las optimizaciones afectan a pequeñas partes de un programa.

Seguir leyendo el post »

Por Juan Barrionuevo

Antipatrones

¿Qué es un antipatrón?

Los antipatrones, como su contrapartida, los patrones de diseño, definen la jerga de la industria para aquellos defectos comunes en los procesos e implementaciones dentro de las organizaciones. Un vocabulario de alto nivel simplifica la comunicación entre desarrolladores de software y permite una descripción concisa de conceptos en un alto nivel.
Un antipatrón, es una forma literal que describe comúnmente a una solución brindada a un problema pero que genera decididamente consecuencias negativas. El antipatrón puede ser el resultado de un diseñador o desarrollador, que por falta de conocimiento de una solución mejor, o no tener suficiente conocimiento o experiencia en resolver ciertos tipos de problemas o simplemente haber aplicado perfectamente un buen patrón en el contexto equivocado.

Seguir leyendo el post »

Por Juan Barrionuevo

Refactoring aplicando patrones

Me topé hace poco con un problema que podría decirse que es bastante común.
El problema puede que sea resultado de un mal análisis o simplemente de un momento de cansancio. Del mismo modo, puede ser que la solución final no sea la mejor.
Pero sinceramente me pareció un caso bastante sencillo para mostrar como un modelo puede evolucionar utilizando patrones.
No podría decir a ciencia cierta si utilicé sólo un patrón, porque como hemos visto hasta el momento, los patrones no son soluciones mágicas que sirven para cualquier modelo o que se aplica de una única manera. Sino que más bien son plantillas que hasta pueden mezclarse entre sí para poder llegar a un resultado que nos resulte útil para que sea escalable.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Visitor

Intención del patrón

• Representar una operación a ejecutarse en los elementos de una estructura de objetos. Visitor permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
• La técnica clásica para recuperar información.
• Hacer lo correcto en función del tipo de dos objetos.
• Duplicar el envío.

Ejemplo de problema

Muchas operaciones distintas y sin relación necesitan ser ejecutadas en una estructura heterogénea de objetos (o nodos). Se desea evitar ensuciar las clases con estas operaciones. Además, no se quiere tener que averiguar el tipo de cada nodo y convertirlo (cast) al tipo correcto antes de ejcutar la operación deseada.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Template method

Intención del patrón

• Define el esqueleto de un algoritmo en una operación, delegando algunos pasos a las clases derivadas del cliente. Template method permite a las subclases redefinir ciertos pasos de un algortimo sin cambiar la estructura del mismo.
• La clase base declara algoritmos "placeholders" y las clases derivadas implementan dichos algoritmos.

Ejemplo de problema

Dos componentes diferentes tienen similitudes significantes, pero no hay una interfaz o implementación común que pueda ser reutilizada. Si un cambio común a ambos componentes resulta necesario, se debe duplicar el esfuerzo en realizar ese cambio.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: Strategy

Intención del patrón

• Definir una familia de algoritmos, encapsular cada uno y hacerlos intercambiables. Strategy le permite al algoritmo variar independientemente del cliente que lo usa.
• Captura la abstracción en una interfaz y encapsula la los detalles de la implementación en clases derivadas.

Ejemplo de problema

Una de las estrategias dominantes del diseño orientado a objeto es el principio Open-close.
La figura muestra cómo se logra habitualmente encapsular los detalles de la interfaz en una clase base y enterrar los detalles de la implementación en las clases derivadas. Los clientes pueden entonces acoplarse a una interfaz y no tener que experimentar los trastornos asociados con el cambio. No hay impacto cuando el número de clases derivadas cambia y tampoco lo hay cuando la implementación de una clase derivada cambia.

Seguir leyendo el post »

Por Juan Barrionuevo

Patrones de diseño de comportamiento: State

Intención del patrón

• Permitir a un objeto cambiar su comportamiento cuando cambia su estado interno. El objeto parecerá cambiar su clase.
• Un estado orientado a objetos.
• Un Wrapper + el objeto envuelto por el Wrapper + colaboración.

Ejemplo de problema

El comportamiento de un objeto monolítico y debe cambiar su comportamiento en tiempo de ejecución según su estado. O bien, una aplicación que se caracteriza por tener extensos y numerosos sentencias case que manejan el control de flujo basado en el estado de la aplicación.

Seguir leyendo el post »

Por Juan Barrionuevo