Los patrones de diseño describen soluciones a problemas de diseño recurrentes. Si bien no hay consenso sobre la forma de integrar patrones de diseño en el desarrollo de software (usando por ejemplo herramientas o lenguajes), si lo hay en cuanto a que la tarea debería ser automatizada o al menos asistida. La experiencia industrial (Beck, 1996) indica que los patrones de diseño reducen los tiempos de desarrollo, facilitan la comunicación, pero su aplicación manual es tediosa, propensa a errores y a pérdida de traceability.
La importancia del diseño de software a partir de patrones de diseño es ampliamente reconocida.
Varios IDEs (Integrated Development Environments) y ambientes de modelado de software basados en UML (OMG, 2004) han comenzado a introducir soporte para patrones de diseño aunque las herramientas comerciales existentes proveen limitada asistencia para la generación de código a partir de los mismos. La mayoría simplemente asiste en un proceso “cortar y pegar”, en el cual el diseñador selecciona un patrón y obtiene una pieza de código en el lenguaje apropiado. El programador necesita luego ajustar el código obtenido a la implementación (Peckham y Lloyd, 2003). En general, las técnicas empleadas no son independientes del lenguaje y son incapaces de generar código en más de un lenguaje.
Estas propuestas asumen que los patrones de diseño involucran clases dedicadas a su rol como el de colaborador dentro de un patrón de diseño particular. En general esto no es verdad, los patrones raramente existen en forma aislada. Con frecuencia un colaborador en un patrón juega un rol diferente en otro. La definición de patrón pone el énfasis en esto: un patrón es "una solución a un problema en un contexto particular" (Gamma y otros,1995). Es más, un patrón es implementado generando no sólo nuevas clases y métodos, sino adaptando el contexto existente, es decir, las construcciones de código preexistentes, a los roles que asumen en el nuevo patrón aplicado (Eden y otros, 1997).