Patronitis

Al final no me he podido resistir. No podía dejarlo para mucho más adelante. Si ayer lo nombraba, hoy me apetecía hablar de una de las enfermedades más comunes de los desarrolladores de software: "la patronitis".

No os molestéis. Este término no aparece en ningún diccionario oficial. Sin embargo, sí puede encontrarse en diversos blogs y libros editados ya hace algunos años. Pero es estos días cuando parece estar más de moda.

En algún blog podemos ver una  definición como:
Patronitis: N. fem. Dícese de la enfermedad propia de programadores que consiste en querer aplicar patrones de diseño a todo.

Sin embargo, no considero esta definición del todo exacta. He podido observar esta enfermedad también en analistas, arquitectos, y otras categorías supuestamente más experimentadas.

Normalmente el problema se debe a nuestra naturaleza friki innata, que nos reclama el uso de todo aquello que hemos aprendido, independientemente de su adecuación al caso. ¿Que no aplica? Pues da igual, se mete, aunque sea con calzador. Y así nos van las cosas. ¿Que se pone de moda la arquitectura de 14 capas? Pues se usa. Luego ya iremos eliminando cosas que realmente sobren. Y el problema es que siempre encontramos un uso para algo.

Una vez me enseñaron una regla de oro, de las que no se deberían olvidar nunca: "Un software no está completo cuando ya no se pueden añadir más funcionalidades, sino cuando no se puede eliminar ni una sola más".

Y es que al final, no es la experiencia en el desarrollo de aplicaciones mediante patrones y la aplicación de las diversas tecnologías lo que nos da la experiencia suficiente para saber dónde está el límite en el uso de los patrones. Es al tener que mantener esas aplicaciones, bien desarrolladas por nosotros mismos, o bien por otros, cuando vemos cuán complicadas son las cosas. Un buen artículo (con algunos añitos a sus espaldas ya), está en: http://www.javahispano.org/contenidos/es/el_peligro_de_los_patrones/
Este artículo es bastante conocido por internet, y tiene muchos seguidores y detractores. Allá cada cual.

Finalmente, para los que os gusta visualizar y ejemplizar las cosas, ahí va una perla: (extraída de: http://odetocode.com/Blogs/scott/archive/2005/11/22/2499.aspx):

Design Patterns: A Love Story

Richard tilted his head to watch the waves push flotsam against the boat hull below. Up and down, the flotsam moved. Up and down.
Richard had an idea.
“Virginia, my dear”, he said to the blond woman beside him. “We’ve been singletons on this ship for a long time”.
“I know, Richard”, she replied. “My mean step-mother, the intercepting filter that she is, denies me time with others.”
Richard paused for a moment, to contemplate strategy. Her father, with his pipes and filters, would return soon, and force them to communicate over his message bus. He glanced aft, and saw no one else around. Richard turned his front controller to face Virginia, and looked her in the eyes. She was close now, and Richard could feel his active record rising.
“Virginia”, he whispered. “There is no observer in sight. Let us run below deck. I want to peel away your façade, and tightly couple.”
“Oh yes, Richard”, she blushed, and leaned towards him. “I want you to give me a dependency injection”.

[Actualizado el 19/02/2015:]
Acabo de ver en el blog de Javier Garzás, un artículo que me ha recordado éste mío. Javier incide en la idea que intento hacer ver en este post, y es que no hay balas de plata, y que las herramientas sólo deben aplicarse cuando aplica. Pero incluso cosas que parecen tan básicas que las tenemos como los cimientos de todo (véase la orientación a objetos, uso de patrones, etc). Si no nos replanteásemos las cosas de vez en cuando...seguiríamos en la prehistoria.