¿Cómo son perjudiciales los patrones de diseño de programación?

En pocas palabras, el mayor problema es cuando uno confunde “patrón” con “estándar”. Cuando Christopher Alexander acuñó el término en su famoso libro “A Pattern Language” ( http://en.m.wikipedia.org/wiki/P …), advirtió que los patrones son simplemente la mejor práctica en ese momento, pero eso es nuevo y surgirán mejores patrones para reemplazarlos. Los patrones no son dogmas a seguir, solo una cuenta de nuestro conocimiento actual.

Pensemos en el patrón de diseño. Es una abstracción de abstracciones. Primero, encontrará algunas buenas abstracciones para implementar diferentes soluciones de software. A continuación, encontrará alguna estructura común, que es común entre tales abstracciones y lo llamará patrón de diseño. A menos que seas Sheldon Cooper (personaje de TV), los patrones de diseño deberían ser exactamente lo último en lo que piensas. Estos pueden aparecer durante el tercer o cuarto ciclo de refactorización de un sistema empresarial muy grande.

Si diseño un sistema de procesamiento de pagos, no tiene ningún sentido pensar en qué patrones en mi diseño son comunes con el diseño del editor de texto de 20 años.

Sin embargo, muchas personas piensan en los patrones de diseño de la misma manera que las bibliotecas reutilizables. En lugar de construir el código en torno a conceptos significativos y relevantes, algunas personas solo buscan la oportunidad de usar el patrón.

1. He visto clases llamadas flyweight, singleton, etc. Este nombre es dañino, porque me da cero información sobre lo que hace esta clase.

2. He visto el código envuelto en tantas capas de interceptores y fábricas que fue imposible encontrar el código, que realmente hace el trabajo.

3.He visto personas creando interfaces, que nunca tuvieron más de una implementación.

4. He visto personas usando el patrón de comando para llamadas RPC síncronas simples, esto condujo a la falta de claridad de la firma del método.

Los patrones de diseño son específicos del contexto. Han aparecido en idiomas particulares, en sistemas particulares, para tipos particulares de aplicaciones. Un patrón podría incluso requerir una expresión sutilmente diferente en diferentes partes del mismo programa.

Los buenos patrones de diseño documentan su contexto y justificación. Entenderlos es entender CUANDO son relevantes. Los problemas surgen cuando las personas pierden de vista cuándo y por qué son importantes y comienzan a aplicarlos fuera de contexto, simplemente porque “están destinados a usar el patrón X”.

Los patrones de diseño se usan por todas las razones equivocadas algunas veces:

• para crear una flexibilidad que no es necesaria, pero “será”
• para demostrar que el desarrollador tiene conocimiento de ellos
• porque el desarrollador los vio aplicados en otro proyecto
• porque son un falso indicador de calidad
• porque la gente no conoce los patrones modernos de la programación funcional y reactiva

Una vez que se coloca un patrón de diseño, es más difícil cambiarlo cuando desaparece el motivo de su implementación.

El mayor problema con los patrones mal aplicados es que oscurecen completamente el significado del código. Atacan la calidad de software más preciada: la legibilidad, la claridad de la intención y el propósito.

Desde mi experiencia, los patrones de diseño son más dañinos cuando se implementan para algo que no sea cumplir con los requisitos establecidos y acordados. La regla de oro es mantenerlo lo más simple posible para completar los requisitos. Las abstracciones, generalizaciones, extensibilidad, reutilización, etc. tienen su propósito, pero en muchos casos pueden conducir a un código más complejo del necesario. También pueden causar problemas importantes con el rendimiento, la depuración y la compatibilidad.

Los patrones de diseño son una herramienta para alcanzar el objetivo, no el objetivo en sí.

Los requisitos claros son la clave, junto con tener un arquitecto con experiencia significativa. Los buenos arquitectos pueden ver los requisitos y predecir las necesidades futuras (registro, seguimiento, problemas de rendimiento, extensibilidad …) que ni siquiera pueden documentarse. Los realmente buenos se asegurarán de que estén integrados en los requisitos para que todos los interesados ​​puedan acordarlos.

La fortaleza de los patrones de diseño es que pueden usarse como una especie de taquigrafía para resolver ciertos tipos de problemas junto con las implicaciones o consecuencias de las elecciones de diseño.

Esas son cosas buenas, pero no sustituyen los requisitos de captura y las decisiones de diseño. Y sin una convención de nomenclatura consistente y una buena documentación, incluso ese conocimiento arquitectónico no se propaga bien.

Los patrones de diseño que se usan hoy en día son aquellos que ayudan en la arquitectura de software de un cierto tipo de problema. Se espera que vayan a facilitar el proceso de desarrollo.

Pueden parecer perjudiciales en ciertos escenarios. Por ejemplo, el programador no comprende completamente la utilidad del patrón de diseño. O si el patrón de diseño se sigue a ciegas.

Considere un buen código como una obra de arte. No puede haber un conjunto de puntos o un libro que defina completamente el arte del desarrollo de software. Usted, como programador, debe comprender eso y no seguir ciegamente los patrones mencionados en trabajos como GoF. Debería ver los patrones de diseño no como estándares, sino como una solución a un problema. Úselo solo si está resolviendo el mismo problema o un problema similar.

Dado que el uso de un patrón de diseño estándar puede no ser bueno para usted, se deduce que debe crear el suyo propio.

Lo que hace que los patrones de diseño sean dañinos es que la mayoría de nosotros lo interpretamos como una forma de * implementar un patrón de diseño *, mientras que un patrón de diseño se trata de tener un diseño para un * patrón de problema *.

Lo que quiero decir es que siempre se crea un patrón de diseño para resolver un conjunto único de problemas. En la práctica, preferimos elegir un patrón de diseño que intente adaptarlo a nuestro problema.

Por lo tanto, perdemos el foco en el problema en sí, a menudo comprometiendo los requisitos para poder decir: ‘Oh … nuestro diseño se basa en un patrón regular’ como si el diseño fuera una especie de truco de marketing.

El patrón de diseño se introdujo como una solución común propuesta para el patrón visto en el mundo real, por lo que uno emula el mundo real, primero aplica el patrón, no el verso, encuentra el problema y luego aplica el patrón, que es lo que sucede la mayor parte del tiempo.
Por ejemplo, el patrón de fábrica se inspiró en la fábrica del mundo real, donde se controla la creación de objetos
Patrón de adaptador inspirado en el voltaje del adaptador donde necesitamos intervenir o poner el voltaje, para que el dispositivo funcione

La forma en que lo veo es que los patrones en sí mismos no son dañinos. La razón por la que surgieron es porque se estaban utilizando con éxito en muchos lugares.

El daño ocurre cuando te excedes. No necesita fábrica abstracta, fábrica, singleton, decoradores y patrón de estrategia para una pieza de código que solo se utilizará durante unas pocas semanas.

A menudo veo ‘arquitectos’ orgullosamente balancear su brillante martillo dorado en cada clavo.

La venganza de los nerds