miércoles, 2 de noviembre de 2011

[6 de 97]. Patronitis.


Post publicado originalmente entre Mayo del 2009 y Enero del 2011 en mi anterior blog.
Pertenece a una serie sobre arquitectura de software, replicaré los comentarios ya que, a mi parecer, son lo más importante de la serie.
Puedes encontrar el listado de esta primera entrega en este enlace.

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:


672 - Earth Day, Green Pac-Man -- Pattern

---

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.

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?]

Saludos a todos!!

RuGI
Isaac Ruiz Guerra.

Comentarios:

Rugi, se nota la buena mano en la redacción de tu post. Gracias por compartir a todos tus experiencias y linkearnos tus sugerencias de lecturas.

Sobre todo he guardado para una lectura posterior el post de JavaHispano de "El peligro de los patrones de Diseño" de Martin.

Y el año pasado estuve viendo algunos documentales de "Redes" donde trabaja Eduard Punset. Muy interesantes por lo demás. Recuerdo que ví uno acerca del "tiempo" (viajes en el tiempo) y otro acerca de los árboles.

Saludos!
Germán.

Enviado por Germán G. en junio 21, 2009 a las 09:23 PM CDT #
---
Mis comentarios de lunes ;-),
Puedo estar de acuerdo en los peligros de la patronitis, pero ojo, en España por lo menos existe otra tendencia AUN más peligrosa: la ignorancia orgullosa de estos.
Un patrón de diseño es una SOLUCIÓN testeada a un problema concreto, así que diseñar un sistema partiendo de soluciones a problemas aún no planteados no tiene sentido. Asi que en lugar de estudiar los patrones, yo estudiaría los PROBLEMAS que resuelven.
En el extremo de la patronitis se encuentran los que acusan de patronitis a todo aquel que no diseñe un sistema como sota,caballo y rey (expresión española: siempre lo mismo)

Así que en ambos extremos tenemos el mismo problema: la ignorancia de los casos concretos que son resueltos por patrones de diseño. En mi caso: los patrones NUNCA me aparecen en el diseño, siempre me aparecen a la hora de programar, cuando me doy cuenta de que no había considerado las peculiaridades del modelo de datos o de las librerías que utilizo.

Por otro lado, los patrones de diseño han traído a la programación una nomenclatura aceptada y entendida; si ves una clase que se llama Factory sabes perfectamente de que trata (de hecho es uno de los consejos de "Clean code", llamar a las clases con nombres conocidos por los programadores). Tal vez han sido un primer paso para convertir esta artesanía en una verdadera ciencia.
Salu2

Enviado por ibon en junio 22, 2009 a las 03:07 AM CDT #
---
Efectivamente como bien dices, lo más importante siempre es que seamos conscientes que a veces la solución más simple no tiene porqué ser un patrón de diseño.

Hemos de utilizarlos, pero no hemos de abusar de ellos; gracias por algunos de los links... los apunto para leer :).

Enviado por Jesús Navarrete en junio 22, 2009 a las 12:34 PM CDT #
---
@Germán, @Jesús gracias por los comentarios; un gusto poder compartir los links... espero les sea de utilidad.

@Ibon,... ahora soy yo él que espera en cada post tus comentarios, y seguramente no soy el único.... mil gracias por ellos. Por cierto, si seguimos así, encontraran estos post's por las referencias a las "expresiones" y "localismos" ;)

Enviado por RuGI en junio 23, 2009 a las 12:25 AM CDT #


----------------------------------
Créditos:
La imagen es de: Patrick Hoesly
http://www.flickr.com/photos/zooboing/4536315433/
La historia fue tomada de: http://odetocode.com/Blogs/scott/archive/2005/11/22/2499.aspx
----------------------------------


No hay comentarios:

Publicar un comentario