[6 de 97]. Patronitis

Seguimos con los axiomas del libro: 97 things Every Software Architech Should Know
El axioma de hoy dice:

"Pattern Pathology"

Chad LaVigne. 

Chad LaVigne, es un arquitecto que trabaja en TEKSystems, Inc, participa activamente en la comunidad openSource y dirige un JUG en las oficinas de su compañía.

Aquí  el axioma casi completo:


Design patterns are one of the most valuable tools available to the software architect.  Using patterns allows us to create common solutions that are easier to communicate and understand.  They are concepts that are directly associated with good design.  This fact can make it very enticing to demonstrate our architectural prowess by throwing a lot of patterns at a project.  If you find yourself trying to shoehorn your favorite patterns into a problem space where they don’t apply, you may be a victim of pattern pathology.

Many projects suffer from this condition.  These are the projects where you envision the original architect looking up from the last page in his patterns book, rubbing his hands together and saying “Now, which one will I use first!?”.  This mentality is somewhat akin to that of a developer who begins writing a class with the thought “hmmm, what class should I extend?”.  Design patterns are excellent tools for mitigating necessary complexity but like all tools, they can be misused.  Design patterns become a problem when we make them the proverbial hammer with which we must strike every nail.  Be careful that your appreciation for patterns doesn’t become an infatuation that has you introducing solutions that are more complicated than they need to be.

Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision.  Keep your sights focused on designing systems that provide effective business solutions and use patterns to solve the problems they address.



Sigo pensando que los patrones de diseño son el primer, o uno de los primeros pasos, para hacer más "exacto" el desarrollo de sistemas informáticos. Lograr , por fin,  transmitir experiencia de una manera mucho más formal y sistemática, han provocado que exista evolución en esta área {para bien de los que nos dedicamos a esto}.

Creo que el axioma anterior se resume en la frase: "No permitas que tu deseo de exhibir tus conocimientos sobre patrones de diseño nuble tu visión práctica."

Esa frase me hizo recordar mucho un famoso artículo que salio en el Java Developer Journal por allá del 2003: ¿Are You Using Abstract Classes, Polymorphism, and Interfaces?, el artículo iniciaba diciendo:
"Si la respuesta es no, tu proyecto necesita mínimamente una revisión de código" (muy recomendable si estas iniciando con algún lenguaje orientado a objetos). Recuerdo que cuando lo leí  inicie una cacería de brujas a mi código y comencé a crear interfaces  y clases abstractas a diestra y siniestra, tiempo después vi que realmente muchas cosas estaban de más (a manera de defensa, al menos me sirvió para comenzar a distinguir cuando elegir una y cuando otra).... ejemplo de exceso.

También recuerdo, y confieso,  que cuando escuche por primera vez  sobre el patrón: Multitón,  lo primero que dije fue: " mmm, cuantas ganas de querer hacer de todo  un patrón".

Decidí hacer esos dos comentarios para mostrar un poco los dos extremos que Chad LaVigne nos trata de advertir: exagerar el uso de ellos o  menospreciarlos.

Según mi perspectiva, parte del problema es que, comparativamente hablando  la arquitectura de software  y los patrones de diseño son conceptos que aún no llegan a un punto estable siquiera en su definición

Fue en  1994 cuando salio el mítico libro: Design Patterns: Elements of Reusable Object-Oriented Software del, más mítico aún, GoF, y ni bien habían pasado 4 años aparece el menos mítico libro: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis de William J. Brown. Entonces, tratar de llegar a acuerdos y convenciones universales en un tema que no deja de moverse, hace que las cosas se compliquen un poco.

Creo que a lo largo de los axiomas que estamos reflexionando juntos, el común denominador será saber ... ¿Hasta cuándo?, ¿Hasta dónde? ¿Que tanto más?.... esa sensibilidad es la que se adquiere con la experiencia, y, para bien o para mal, la manera más común para adquirir experiencia es con vivencias, y las vivencias transcurren en el tiempo.. luego entonces, nos sensibilizaremos con el tiempo ;)

Martin  tiene claro lo que intento advertir en su artículo: El peligro de los patrones de diseño,  con la frase: "Hay que saber resistirse a la euforia".

Debemos alcanzar una especie de nivel reflexivo que nos permita no caer en estados de euforia o de "autocomplacencia", evitar el , como decimos aquí en México para justificar que no logramos mesurarnos  adecuadamente en algo: "¡¡¡ Total !!!,.. ¿Qué tanto es tantito?"

Quisiera concluir la reflexión de este axioma con un fragmento de texto que reproduce lo que Eduardo Punset menciona en la entrada de su blog:

"Dar {lugar}a la emoción que uno siente cuando esta realizando lo que le gusta no debería de interferir con lo que llaman los procesos cognitivos de funciones ejecutivas, es decir {emocionarse},  no debería interferir con la pericia, con la habilidad {de hacer bien las cosas}"

Blog de Eduardo punset.
"Es preciso emocionarse, pero no tanto."

Y, por supuesto.... iniciemos la semana con una sonrisa :)
Perdón por no traducir, pero, me parece, se entiende mejor en su idioma original... y, no me gustaría evocar el famoso proverbio italiano: «Traduttore, traditore»

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”. [Author’s note: I’m sorry. I can’t continue. Shortly after typing the words “give me a dependency injection”, I was overcome by a sudden sickness and fell to the floor in convulsions. Let’s just assume the story has a happy ending, and forget this post ever happened. OK?]

Tomado de: http://odetocode.com/Blogs/scott/archive/2005/11/22/2499.aspx

Saludos a todos!!

----
RuGI
Isaac Ruiz Guerra.

Posted at 08:31PM jun 21, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[5]