[SPA] FAQ sobre patrones

Hoy quiero escribir sobre algunas preguntas que me hacen sobre el tema patrones.

¿Qué son?

Los patrones son soluciones contrastadas a problemas recurrentes en el desarrollo y diseño de software. Para que una solución se considere un patrón debe tener algunas características como, por ejemplo, demostrar que se puede aplicar en diferentes tecnologías, es decir es un conocimiento agnóstico y reusable, que puede descomponerse en responsabilidades o roles bien definidos, y que ha demostrado su eficacia bajo ciertas circunstancias. A esas circunstancias se le da el nombre de fuerzas y son los motivos para usar el patrón y para identificarlo de otro diferente.

¿Porque tengo que conocerlos?

Por suerte ¡no hay un solo porqué! sino que hay varios motivos para que los conozcas.

Porque no necesitas reinventar la rueda. Los patrones pretenden evitar la reiteración de búsquedas de soluciones a problemas ya conocidos, que no re inventes la rueda.

Porque iras en hombros de gigantes. Si, si... Estarás aplicando soluciones que cientos de arquitectos con muchísima experiencia han usado y refinado a lo largo de los años.

Porque te ayudarán a estructurar tu código. Los patrones tienen roles o participantes bien definidos. Por ejemplo, en un patrón Observer, está el que observa y el sujeto observado. De esta manera evitaras programar todo junto en una sola clase.

Porque serán parte de tu jerga de desarrollador. Esto es como la policía que dice “es un 3218” y lo entienden solo ellos. Pues con los patrones dirás “Hay que hacer un Abstract Factory” y todos los desarrolladores deberían saber de qué estás hablando. Es más, deberían pensar en los diferentes roles del patrón.

Porque formalizaras el diseño. Sin llegar al caso extremo de “Para un martillo todos los problemas son clavos”, ni tampoco pretendiendo erradicar la creatividad, lo que buscan los patrones es que si tu solución se ha encontrado con un problema que tenga la solución testeada. Si en tu solución tienes unas estructuras de árbol deberías encontrarte con un patrón Composite.

Porque se están dando a conocer más. En los últimos años, he visto como diferentes lenguajes y framework iban agregando patrones. Algunos de ellos son:

1. Los iteradores (foreach) en lenguajes OO.
2. Abstract Factory en ADO.NET para crear conexiones y comandos.
3. WPF y los commands para ejecutar acciones de UI.
4. Aspnet y el cambio radical en el uso de MVC para gestionar las peticiones http.
5. Framework js de tipo MV* y los observables (Knockout, Angular, Aurelia, Vue, por nombrar algunos) para mantener el html actualizado.
6. Rx.Net y el uso de observables.
7. NodeJs y su event loop. Si quieres saber porque Node es tan rápido debes conocer este patrón.
8. Redux y su estado inmutable.

Si alguien se te acerca y te dice que los patrones son una pérdida de tiempo y que lo usan 4 friquis, ya tienes argumentos para decir que no es así.

Porque serán la mejor inversión profesional que puedes realizar. Esto no es un framework de Javascript que hoy sale uno y en 6 meses otro y tienes que estar saltando de un “Getting Started” o a otro. Esto es un conocimiento base que después vas aplicando en diferentes lenguajes de programación. Si todavía te quedan dudas te cuento mi experiencia. Aprendí sobre patrones antes del año 2000. En aquel entonces programaba en Visual Basic 6, aquel que no era 100% orientado a objetos porque tenia interfaces, pero no tenía herencia. Empecé a desarrollar patrones que se basan en interfaces como adapter o strategy con VB, y para los que usan herencia empecé a escribirlos en Java, hasta que en el 2001 pude hacerlos en C#. Hace cosa de 2 años, me tocó trabajar en un proyecto donde aplique patrones en la interfaz de usuario con typescript. ¿cuanto conocimiento tecnológico puedes usar despues de 15 años?

Pero si esto yo ya lo hago!!

Es muy posible que si estructuras bien tu código ya estés usando algún patrón, pero sin saberlo. Si estas en ese grupo, ¡eres un maquina! Ahora apréndete el nombre del patrón y podrás comunicarte mejor con otros programadores.

¿Hace falta conocerlos todos?

No, no hace falta. Mi consejo es que primero intentes asociar el problema - o como decia al principio, las fuerzas - y el nombre del patrón que lo resuelve. Cuando tengas el problema, recordando el nombre podrás buscarlo en internet para ver alguna implementación en algún blog o en GitHub. Después apréndete bien aquellos que consultes más.

Lo que si tienes que saber es que hay diferentes patrones para diferentes paradigmas o ámbitos. Por nombrar algunos tienes patrones de programación orientada a objetos, de programación funcional, de cloud, de concurrencia, de domain driven design, etc.

¿Qué diferencia hay con los principios de desarrollo?

Te lo explico con un ejemplo. Si quieres diseñar un coche que tenga adherencia, tienes que hacerlo con tracción delantera. Esto es un ejemplo de problema recurrente y solución asociada, es decir un patrón. Siguiendo con el ejemplo, los principios serían las normas básicas para que un motor funcione.

Los principios de desarrollo representan una guía que te ayuda a tener código fácil de mantener y fácil de cambiar, y que no sea frágil ante el cambio - aquello de que tocas en un lado y deja de fusionar otro. Para mis los principios están antes que los patrones, y los patrones suelen aplicar estos principios.

¿Hay que usarlos siempre?

No, forzar el uso de un patrón suele ser un error. Volvemos por un minuto a la pregunta anterior. Hay un principio que se llama YAGNI, que viene a decir que no hagas algo que no necesitas. Y créeme, hay dos cosas que nunca necesitaras, una arquitectura mal hecha y una sobre-arquitectura, que al final no es otra cosa que una arquitectura mal hecha.

Conclusión

He usado patrones por más de 15 años y seguiré usándolos por las ventajas que ofrece. Te insto a que puedas aprender sobre ellos y usarlos. El coste beneficio es bestial.