Elegir el patrón de diseño correcto

Siempre he reconocido la importancia de utilizar patrones de diseño. Tengo curiosidad por saber cómo otros desarrolladores eligen el más adecuado. ¿Utiliza una serie de características (como un diagrama de flujo) para ayudarlo a decidir?

Por ejemplo:

Si los objetos están relacionados, pero no queremos especificar una clase concreta, considere Resumen

Cuando se deja la instanciación a clases derivadas, considere Factory

Necesita acceder a elementos de un objeto agregado secuencialmente, intente Iterator

¿o algo similar?

Una idea errónea clave en el mundo de la codificación actual es que los patrones son bloques de construcción. Toma un AbstractFactoryaquí y un Flyweightallá y quizás un Singletonallá y los conecta con XML y listo, tiene una aplicación que funciona.

Ellos no están.

Hmm, eso no fue lo suficientemente grande.

Los patrones no son bloques de construcción

Eso es mejor.

Un patrón es algo que usa cuando descubre que tiene un problema: necesita cierta flexibilidad que proporciona el patrón o que se ha tropezado cuando está haciendo un pequeño lenguaje en el archivo de configuración y dice "espera un momento, detente, este es su propio intérprete que estoy escribiendo: este es un problema conocido y resuelto, usa un patrón de intérprete ".

Pero tenga en cuenta que es algo que descubre en su código, no algo con lo que comienza. Los creadores de Java no dijeron "Oh, pondremos un Flyweight en el número entero" al principio, sino que se dieron cuenta de un problema de rendimiento que podría resolver un flyweight .

Y por lo tanto, no hay un "diagrama de flujo" que use para encontrar el patrón correcto. El patrón es una solución a un tipo específico de problema que se ha encontrado una y otra vez y las partes clave del mismo se destilaron en un Patrón.

Comenzar con el Patrón es como tener una solución y buscar un problema. Esto es algo malo: conduce a una ingeniería excesiva y, en última instancia, a la inflexibilidad en el diseño.

Mientras escribe el código, cuando se da cuenta de que está escribiendo una Fábrica, puede decir "¡ah, es una fábrica que estoy a punto de escribir" y usar su conocimiento de conocer el patrón de Fábrica para escribir rápidamente el siguiente fragmento de código sin intentar redescubrir el patrón Factory. Pero no comienzas con "Tengo una clase aquí, escribiré una fábrica para que sea flexible", porque no lo hará.

Aquí hay un extracto de una entrevista con Erich Gamma (de Gamma, Helm, Johnson y Vissides ): Cómo usar patrones de diseño :

Intentar usar todos los patrones es algo malo, porque terminarás con diseños sintéticos, diseños especulativos que tienen una flexibilidad que nadie necesita. En estos días el software es demasiado complejo. No podemos permitirnos especular qué más debería hacer. Necesitamos centrarnos realmente en lo que necesita. Por eso me gusta refactorizar los patrones. Las personas deben aprender que cuando tienen un tipo particular de problema u olor a código, como lo llaman en estos días, pueden ir a su caja de herramientas de patrones para encontrar una solución.

La mejor ayuda para el "qué usar, cuándo" es probablemente la página de Wikipedia para el patrón de diseño de software : la sección "Clasificación y lista" describe la categoría en la que se encuentra cada patrón y qué hace. No hay diagrama de flujo; la descripción allí es probablemente la mejor que encontrará como un breve fragmento de "qué usar, cuándo".

Tenga en cuenta que encontrará diferentes patrones en diferentes áreas de programación. El diseño web tiene su propio conjunto de patrones, mientras que JEE (no el diseño web) tiene otro conjunto de patrones. Los patrones para la programación financiera son completamente diferentes a los del diseño de interfaz de usuario de aplicaciones independientes.

Por lo tanto, cualquier intento de enumerarlos a todos es inherentemente incompleto. Usted encuentra uno, descubre cómo usarlo y luego eventualmente se convierte en una segunda naturaleza y no necesita pensar cómo o cuándo volver a usarlo (hasta que alguien le pida que se lo explique).

Me pregunto:

1. ¿Qué problema estoy tratando de resolver?
2. ¿Qué patrón de diseño de software (si lo hay) resuelve más de cerca el mismo problema o proporciona una ruta lógica para resolver mi problema?
3. ¿Necesito la abstracción adicional (y la complejidad) que proporciona el patrón, o es una ingeniería excesiva para mi problema particular? ¿Se puede resolver el problema de una manera más simple y eficiente sin el patrón?

El proceso de elegir un patrón de software no es diferente al proceso de elegir una estructura de datos, excepto que al elegir una estructura de datos, evaluaría el rendimiento y las características de la memoria de su problema, y ​​elegiría la estructura de datos que más se ajuste a esas características.