Anti-Patterns

Para poder entender el concepto, primero debemos entender lo que es un patrón, en una definición muy simple, un patrón es una forma reutilizable para resolver, problemas recurrentes en el desarrollo de software. Como si fuera una plantilla que podemos aplicar a otro problema para solucionar su implementación.

Un Anti-patrón es un patrón, que es usado comúnmente, pero que resulta ser ineficiente, no es efectivo y puede hasta resultar contraproducente en la práctica. Esto quiere decir que no basta con que mucha gente lo utilice, eso no lo hace un patrón.

No debemos confundirlo con mal hábito, mala práctica o mala idea; un anti-patrón es más complejo que estos. Para distinguirlos se debe identificar en el código, una acción repetida, que en primera instancia parece beneficiar al código, pero que en realidad resulta negativo, hace que nuestro código no pueda ser refactorizable, hace el código más complejo de entender, difícil de dar mantenimiento. De ahí que resulte difícil diferenciarlos entre sí.

 

Porque es importante conocerlo?

Así como al conocer los patrones podemos aplicarlos en nuestro código y de esta forma mejoramos la calidad de nuestro trabajo; al conocer lo anti-patrones, podemos prevenir su uso, lo que redunda en mejor calidad a su vez.

 

Algunos anti-patrones son:

Espectador apático: Resulta que si se da cuenta del error, pero no hace nada, porque afecta a muchos.

Inversión de la abstracción: Ocurre cuando un programador en vez de usar los métodos de la clase abstracta, de la cual heredo, implementa los mismos métodos, a veces sobre escribiendo lo originales. Lo que ocasiona confusión en los programadores que heredan esta clase.

Gran bola de lodo: Ocurre cuando se programa sin realizar un diseño arquitectónico de la aplicación, cuando la aplicación crece de forma cancerosa o tumoral, hacía lugares desconocidos, cuando hay promiscuidad entre partes que deberían ser independientes, cuando la información es global o esta duplicada por todos lados, es el resultado de desarrollar con la inercia del día a día.

Capa de oro: Cuando seguimos agregándole a nuestra aplicación características y funcionalidades en la creencia ingenua que al usuario le va a complacer, en vez de preguntarle qué es lo que necesita.

Efecto de plataforma central: Es la tendencia a tratar de hacer aplicaciones personalizables, altamente configurables; por ejemplo agregándole plug-ins, o add-ons a una aplicación para mejorar sus funcionalidades, sin que ese haya sido el diseño desde el principio.

Hinchazón de interface: Es hacer una aplicación tan poderosa, que resulta muy difícil de implementar.

Modelo Anémico: Es el uso de un modelo sin lógica de negocios, de tal forma que nuestro modelo no puede garantizar su integridad, por que se encuentra fuera de su alcance.

Vagón Gitano: Son objetos que se crean con la simple idea de pasar información a otros objetos, sin que sean usados para realizar ningún proceso, simplemente aparecen y desaparecen en la línea de parámetros, por este motivo también se llama al anti-patrón Poltergeist. NO debemos confundir estos objetos con lo que surgen en el Patrón MVC cuya función es clara y juegan un papel importante para el desempeño.

Acoplamiento Secuencial: Ocurre cuando una clase requiere que sus método deban ser ejecutados en un orden predefinido, lo que ocasiona que parte de la lógica interna de la clase sea controlada por la clase que crea la instancia.

 

Comentario final:

Estos solo son algunos de los anti-patrones que día a día se identifican y agregan a la larga lista; si quieren leer mas del tema pueden visitar esta dirección: http://www.antipatterns.com/AntiPatterns/Welcome.html o esta otra: http://c2.com/cgi/wiki?AntiPatternsBook.

Creo que podemos concluir que incluso de los errores podemos sacar alguna enseñanza, es de sabios reconocer que estamos haciendo mal las cosas y enderezar el camino.