Hace unos días, platicando con algunos amigos en el IRC surgió el tema de la POO(Programación Orientada a Objetos) y al ver cómo se iba desarrollando el tema, descubrí que hay mucha desinformación y confusión con respecto a la POO.
Primero que nada, lanzo los siguientes enunciados que, segun mis años de experiencia, son ciertos:
* El que alguien sepa los conceptos básicos de POO(Encapsulamiento, herencia, polimorfismo, etc.), No lo hace automáticamente un buen programador Orientado a Objetos.
* El que alguien sepa, además de lo anterior, todos los recovecos, palabras reservadas, librerías, expresiones lambda, delegados, eventos, etc. de un lenguaje de programación, No lo hace automáticamente un buen programador Orientado a Objetos.
* El que alguien, además del punto anterior, recite de memoria todos los elementos que forman la última implementación de MVC, MVVM, MVP o cualquier otro framework que implemente o se base en un patrón o patrones de diseño y pueda hacer programas con él, No lo hace automáticamente un buen programador Orientado a Objetos.
Más de uno, lo sé, se mostrará sorprendido... sobre todo con la última afirmación. ¿Cómo podría alguien con un nivel de conocimiento tal, que supiera el manejo y la implementación de MVC de MS por ejemplo no ser un buen programador orientado a objetos? muy sencillo, he visto cada vez con mayor frecuencia un fenómeno provocado, creo yo, por el tren de vida de este mundo globalizado, en el que todo es urgente, en el que la competencia se hace cada vez más dura, en el que "no hay tiempo para aprender todos los detalles", y que consiste en elegir uno o varios de estos frameworks y "casarlos" con los proyectos que tengamos planeado realizar dependiendo casi únicamente del tipo de proyecto (MVC para proyectos web, MVVM o MVP y WPF para proyectos de escritorio, etc.) este fenómeno, conocido en el mundo de los antipatrones de diseño como "Golden Hammer", desgraciadamente ha estado cobrando fuerza.
Y el problema no son en sí los frameworks, los cuales son piezas de valiosa ayuda para nosotros... sino la forma en que los usamos. Esa tendencia a veces inconsciente de querer "convertir en un clavo" ese proyecto que traemos entre manos solo para poder decir "ajá... pues la solución es usar mi martillo".
Los frameworks como MVC, MVVM, MVP, etc. están basados en uno o mas Patrones de diseño (patrones de arquitectura para ser más exacto), por lo que su uso debiera ser regido también por las reglas y consejos que se dan en cada uno de estos patrones.
En la última parte del libro "Head First: Design Patterns" hay un mensaje muy importante con respecto a los patrones de diseño:
"Los patrones de diseño son una herramienta, la cual debe ser usada solo cuando se necesita. ¿Por qué? porque los patrones de diseño introducen complejidad al código, y nunca queremos complejidad cuando no se necesita. Durante este libro también has invertido mucho tiempo aprendiendo los principios del Diseño Orientado a Objetos. Siempre comienza aplicando los principios y creando el código mas simple que pueda hacer el trabajo, y si en el camino surge la necesidad de usar un patron de diseño, entonces úsalo. Los patrones son poderosos cuando se usan si realmente se ocupan. Son fragmentos de experiencia probada que, además, permiten comunicarse de forma eficiente al utilizar un vocabulario común."¿A qué principios se refiere el libro? pues nada menos que a los principios de Diseño Orientado a Objetos, no a los conceptos básicos de encapsulamiento, herencia, polimorfismo, etc. sino a algo más abstracto y mas profundo. Se refiere al SRP, OCP, LSP, ISP, DIP, etc.(Definitivamente dedicaré un post a estos principios, empezando por los que forman el acrónimo SOLID). Estos principios, son la base de todos los patrones de diseño, aplicando estos principios es como se puede determinar si se ocupará o no un patrón de diseño, esto, combinado con las características MUY ESPECIALES de cada proyecto
Como dice Martin Fowler en su libro "Patterns of Enterprise Application Architecture":
"Una vez que sabes que necesitas un patrón, tienes que averiguar cómo aplicarlo en tus circunstancias. Una clave del uso de los patrones es que nunca lo aplicas tal cual a ciegas, es por eso que las herramientas basadas en patrones fallan tan miserablemente. Me gusta decir que los patrones estan "a medio cocinar", eso significa que siempre tienes que darles el toque final en el horno de tu proyecto. Cada vez que uso un patrón le ajusto un poco aquí y allá. Puedes ver la misma solución infinidad de veces, pero nunca es exactamente igual."Y concluye:
"Siempre recuerda que cada patrón está incompleto y que tienes la responsabilidad, y la diversión, de completarlo en el contexto de tu propio sistema."En fin que, para no hacer este post mas largo, considero que lo que en realidad te hace un buen Programador Orientado a Objetos, es conocer y saber aplicar los principios del Diseño Orientado a Objetos y los Patrones de Diseño, no el saberte de memoria un par de frameworks, claro que es bueno saberte los frameworks, sobre todo porque te dan ventajas competitivas y te ahorran esfuerzo, pero si no conoces el trasfondo de ellos, ni los principios en los cuales se basan, no siempre podrás aplicarlos cuando se necesiten, o lo que es peor, intentarás aplicarlos cuando NO se necesiten, te sentirás limitado cuando veas que hay algo que "no encaja" o que sientas que "falta algo" para que la solución funcione como esperas... pero ¿Te digo algo? no es culpa del framework...
Concluyo con un texto que escribió Martin Fowler al final de un artículo que publicó hace algunos años llamado "Quien necesita un Arquitecto", y el cual deja ver sin lugar a dudas qué es lo que nos limita cuando hacemos o diseñamos los sistemas:
"El software no está limitado por la física,como lo están las construcciones. Está limitado por la imaginación, por el diseño y la organización. Eso significa que está limitado por las características de las personas, no por las características del mundo. Hemos encontrado al enemigo... somos nosotros mismos."
