Patrón de diseño de software

Solución reutilizable para un problema de software común

En ingeniería de software , un patrón de diseño de software es una solución general y reutilizable para un problema que ocurre comúnmente dentro de un contexto dado en el diseño de software . No es un diseño terminado que pueda transformarse directamente en código fuente o máquina . Más bien, es una descripción o plantilla de cómo resolver un problema que se puede utilizar en muchas situaciones diferentes. Los patrones de diseño son las mejores prácticas formalizadas que el programador puede utilizar para resolver problemas comunes al diseñar una aplicación o un sistema.

Los patrones de diseño orientados a objetos suelen mostrar relaciones e interacciones entre clases u objetos , sin especificar las clases u objetos finales de la aplicación que están involucrados. Los patrones que implican un estado mutable pueden no ser adecuados para lenguajes de programación funcionales . Algunos patrones pueden volverse innecesarios en lenguajes que tienen soporte incorporado para resolver el problema que están tratando de resolver, y los patrones orientados a objetos no son necesariamente adecuados para lenguajes no orientados a objetos.

Los patrones de diseño pueden verse como un enfoque estructurado a la programación de computadoras intermedio entre los niveles de un paradigma de programación y un algoritmo concreto .

En un estudio de revisión de 2020, Wedyan y Abufakher investigan los patrones de diseño y la calidad del software y concluyen: "Nuestro estudio ha demostrado que los estudios primarios proporcionan una evidencia empírica sobre el efecto positivo de la documentación de instancias de patrones de diseño en la comprensión del programa y, por lo tanto, en la mantenibilidad. Si bien este resultado no es sorprendente, tiene, sin embargo, dos indicaciones. En primer lugar, los desarrolladores deberían esforzarse más para agregar dicha documentación, aunque sea en forma de comentarios simples en el código fuente. En segundo lugar, al comparar los resultados de diferentes estudios, el debe tenerse en cuenta el efecto de la documentación ". ^[1]

Historia

Los patrones se originaron como un concepto arquitectónico por Christopher Alexander ya en 1977 (cf. "The Pattern of Streets", REVISTA DE LA AIP, septiembre de 1977, Vol. 32, No. 3, pp. 273-278). En 1987, Kent Beck y Ward Cunningham comenzaron a experimentar con la idea de aplicar patrones a la programación, específicamente lenguajes de patrones , y presentaron sus resultados en la conferencia OOPSLA de ese año. ^{[2] [3]} En los años siguientes, Beck, Cunningham y otros siguieron con este trabajo.

Los patrones de diseño ganaron popularidad en la informática después de que el libro Design Patterns: Elements of Reusable Object-Oriented Software fuera publicado en 1994 por la llamada "Gang of Four" (Gamma et al.), Que con frecuencia se abrevia como "GoF". Ese mismo año, se llevó a cabo la primera Conferencia de lenguajes de programación de patrones , y al año siguiente se creó el repositorio de patrones de Portland para la documentación de patrones de diseño. El alcance del término sigue siendo motivo de controversia. Los libros notables en el género de patrones de diseño incluyen:

• Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John (1995). Patrones de diseño: elementos de software orientado a objetos reutilizable . Addison-Wesley . ISBN 978-0-201-63361-0.
• Brinch Hansen, Per (1995). Estudios en Ciencias Computacionales: Paradigmas de Programación Paralela . Prentice Hall. ISBN 978-0-13-439324-7.
• Buschmann, Frank ; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter (1996). Arquitectura de software orientada a patrones, volumen 1: un sistema de patrones . John Wiley e hijos. ISBN 978-0-471-95869-7.
• Beck, Kent (1997). Patrones de mejores prácticas de Smalltalk . Prentice Hall. ISBN 978-0134769042.
• Schmidt, Douglas C .; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000). Arquitectura de software orientada a patrones, volumen 2: patrones para objetos simultáneos y en red . John Wiley e hijos. ISBN 978-0-471-60695-6.
• Fowler, Martin (2002). Patrones de arquitectura de aplicaciones empresariales . Addison-Wesley . ISBN 978-0-321-12742-6.
• Hohpe, Gregor; Woolf, Bobby (2003). Patrones de integración empresarial: diseño, creación e implementación de soluciones de mensajería . Addison-Wesley . ISBN 978-0-321-20068-6.
• Freeman, Eric T .; Robson, Elisabeth; Bates, Bert; Sierra, Kathy (2004). Patrones de diseño de Head First . O'Reilly Media . ISBN 978-0-596-00712-6.

Aunque los patrones de diseño se han aplicado prácticamente durante mucho tiempo, la formalización del concepto de patrones de diseño languideció durante varios años. ^[4]

Práctica

Los patrones de diseño pueden acelerar el proceso de desarrollo al proporcionar paradigmas de desarrollo probados y comprobados. ^[5] El diseño de software eficaz requiere considerar problemas que pueden no ser visibles hasta más adelante en la implementación. El código recién escrito a menudo puede tener problemas sutiles ocultos que tardan en detectarse, problemas que a veces pueden causar problemas importantes en el futuro. La reutilización de patrones de diseño ayuda a prevenir estos problemas sutiles, ^[6] y también mejora la legibilidad del código para los codificadores y arquitectos que están familiarizados con los patrones.

Para lograr flexibilidad, los patrones de diseño suelen introducir niveles adicionales de direccionamiento indirecto , que en algunos casos pueden complicar los diseños resultantes y perjudicar el rendimiento de la aplicación.

Por definición, un patrón debe programarse de nuevo en cada aplicación que lo utilice. Dado que algunos autores ven esto como un paso atrás de la reutilización de software proporcionada por los componentes , los investigadores han trabajado para convertir patrones en componentes. Meyer y Arnout pudieron proporcionar una componenteización total o parcial de dos tercios de los patrones que intentaron. ^[7]

Las técnicas de diseño de software son difíciles de aplicar a una gama más amplia de problemas. ^{[ cita requerida ] Los} patrones de diseño brindan soluciones generales, documentadas en un formato que no requiere detalles específicos vinculados a un problema en particular.

Estructura

Los patrones de diseño se componen de varias secciones (ver § Documentación a continuación). De particular interés son las secciones Estructura, Participantes y Colaboración. Estas secciones describen un motivo de diseño : una microarquitectura prototípica que los desarrolladores copian y adaptan a sus diseños particulares para resolver el problema recurrente descrito por el patrón de diseño. Una microarquitectura es un conjunto de componentes del programa (por ejemplo, clases, métodos ...) y sus relaciones. Los desarrolladores utilizan el patrón de diseño al introducir en sus diseños esta microarquitectura prototípica, lo que significa que las microarquitecturas en sus diseños tendrán una estructura y organización similar al motivo de diseño elegido.

Patrones específicos de dominio

También se han realizado esfuerzos para codificar patrones de diseño en dominios particulares, incluido el uso de patrones de diseño existentes, así como patrones de diseño específicos de dominio. Los ejemplos incluyen patrones de diseño de interfaz de usuario , ^[8] visualización de información , ^[9] diseño seguro, ^[10] "usabilidad segura", ^[11] diseño web ^[12] y diseño de modelos de negocio. ^[13]

Las actas de la Conferencia anual sobre lenguajes de programación de patrones ^[14] incluyen muchos ejemplos de patrones específicos de dominio.

Clasificación y lista

Los patrones de diseño se habían categorizado originalmente en 3 subclasificaciones según el tipo de problema que resuelven. Los patrones de creación brindan la capacidad de crear objetos basados ​​en un criterio requerido y de forma controlada. Los patrones estructurales tratan de organizar diferentes clases y objetos para formar estructuras más grandes y proporcionar nuevas funcionalidades. Finalmente, los patrones de comportamiento tratan de identificar patrones de comunicación comunes entre objetos y darse cuenta de estos patrones.

Patrones de creación

Nombre	Descripción	En Patrones de Diseño	En código completo [15]	Otro
Fábrica abstracta	Proporcione una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas.	sí	sí	N / A
Constructor	Separar la construcción de un objeto complejo de su representación, permitiendo que el mismo proceso de construcción cree varias representaciones.	sí	No	N / A
Inyección de dependencia	Una clase acepta los objetos que requiere de un inyector en lugar de crear los objetos directamente.	No	No	N / A
Método de fábrica	Defina una interfaz para crear un solo objeto, pero deje que las subclases decidan qué clase instanciar. El método de fábrica permite que una clase difiera la instanciación a subclases.	sí	sí	N / A
Inicialización perezosa	Táctica de retrasar la creación de un objeto, el cálculo de un valor o algún otro proceso costoso hasta la primera vez que se necesita. Este patrón aparece en el catálogo de GoF como "proxy virtual", una estrategia de implementación para el patrón Proxy .	No	No	PoEAA [16]
Multiton	Asegúrese de que una clase solo tenga instancias con nombre y proporcione un punto global de acceso a ellas.	No	No	N / A
Grupo de objetos	Evite la adquisición y liberación de recursos costosos mediante el reciclaje de objetos que ya no se utilizan. Puede considerarse una generalización del grupo de conexiones y los patrones del grupo de subprocesos .	No	No	N / A
Prototipo	Especifique los tipos de objetos que se crearán utilizando una instancia prototípica y cree nuevos objetos a partir del 'esqueleto' de un objeto existente, aumentando así el rendimiento y manteniendo la huella de memoria al mínimo.	sí	No	N / A
La adquisición de recursos es inicialización (RAII)	Asegúrese de que los recursos se liberen correctamente atándolos a la vida útil de los objetos adecuados.	No	No	N / A
único	Asegúrese de que una clase tenga solo una instancia y proporcione un punto global de acceso a ella.	sí	sí	N / A

Patrones estructurales

Nombre	Descripción	En Patrones de Diseño	En código completo [15]	Otro
Adaptador , envoltorio o traductor	Convierta la interfaz de una clase en otra interfaz que esperan los clientes. Un adaptador permite que las clases trabajen juntas que de otra manera no podrían debido a interfaces incompatibles. El patrón de integración empresarial equivalente es el traductor.	sí	sí	N / A
Puente	Desacople una abstracción de su implementación permitiendo que las dos varíen de forma independiente.	sí	sí	N / A
Compuesto	Componga objetos en estructuras de árbol para representar jerarquías de parte y todo. Composite permite a los clientes tratar objetos individuales y composiciones de objetos de manera uniforme.	sí	sí	N / A
Decorador	Adjunte responsabilidades adicionales a un objeto manteniendo dinámicamente la misma interfaz. Los decoradores brindan una alternativa flexible a las subclases para extender la funcionalidad.	sí	sí	N / A
Objeto de extensión	Agregar funcionalidad a una jerarquía sin cambiar la jerarquía.	No	No	Desarrollo de software ágil, principios, patrones y prácticas [17]
Fachada	Proporcionar una interfaz unificada a un conjunto de interfaces en un subsistema. Facade define una interfaz de nivel superior que facilita el uso del subsistema.	sí	sí	N / A
Peso mosca	Utilice el uso compartido para admitir una gran cantidad de objetos similares de manera eficiente.	sí	No	N / A
Controlador frontal	El patrón se relaciona con el diseño de aplicaciones web. Proporciona un punto de entrada centralizado para manejar solicitudes.	No	No	Patrones J2EE [18] PoEAA [19]
Marcador	Interfaz vacía para asociar metadatos con una clase.	No	No	Java efectivo [20]
Módulo	Agrupe varios elementos relacionados, como clases, singletons, métodos, utilizados globalmente, en una sola entidad conceptual.	No	No	N / A
Apoderado	Proporcione un sustituto o marcador de posición para otro objeto para controlar el acceso a él.	sí	No	N / A
Gemelo [21]	Twin permite el modelado de herencia múltiple en lenguajes de programación que no admiten esta función.	No	No	N / A

Patrones de comportamiento

Nombre	Descripción	En Patrones de Diseño	En código completo [15]	Otro
Pizarra	Patrón de inteligencia artificial para combinar fuentes de datos dispares (ver sistema de pizarra )	No	No	N / A
Cadena de responsabilidad	Evite vincular el remitente de una solicitud a su receptor dando a más de un objeto la oportunidad de manejar la solicitud. Encadene los objetos receptores y pase la solicitud a lo largo de la cadena hasta que un objeto la maneje.	sí	No	N / A
Mando	Encapsular una solicitud como un objeto, lo que permite la parametrización de clientes con diferentes solicitudes y la puesta en cola o registro de solicitudes. También permite el soporte de operaciones que se pueden deshacer.	sí	No	N / A
Interprete	Dado un idioma, defina una representación para su gramática junto con un intérprete que use la representación para interpretar oraciones en el idioma.	sí	No	N / A
Iterador	Proporcionar una forma de acceder a los elementos de un objeto agregado de forma secuencial sin exponer su representación subyacente.	sí	sí	N / A
Mediador	Defina un objeto que encapsule cómo interactúa un conjunto de objetos. El mediador promueve el acoplamiento flexible al evitar que los objetos se refieran entre sí de manera explícita y permite que su interacción varíe de forma independiente.	sí	No	N / A
Recuerdo	Sin violar la encapsulación, capture y externalice el estado interno de un objeto permitiendo que el objeto sea restaurado a este estado más tarde.	sí	No	N / A
Objeto nulo	Evite referencias nulas proporcionando un objeto predeterminado.	No	No	N / A
Observador o Publicar / suscribirse	Defina una dependencia de uno a varios entre objetos donde un cambio de estado en un objeto da como resultado que todos sus dependientes sean notificados y actualizados automáticamente.	sí	sí	N / A
Servidor	Defina una funcionalidad común para un grupo de clases. El patrón de sirviente también se denomina con frecuencia implementación de clase de ayuda o de clase de utilidad para un conjunto dado de clases. Las clases auxiliares generalmente no tienen objetos, por lo tanto, tienen todos los métodos estáticos que actúan sobre diferentes tipos de objetos de clase.	No	No	N / A
Especificación	Lógica empresarial recombinable de forma booleana .	No	No	N / A
Estado	Permitir que un objeto altere su comportamiento cuando cambia su estado interno. El objeto parecerá cambiar su clase.	sí	No	N / A
Estrategia	Defina una familia de algoritmos, encapsule cada uno y conviértalos en intercambiables. La estrategia permite que el algoritmo varíe independientemente de los clientes que lo utilicen.	sí	sí	N / A
Método de plantilla	Defina el esqueleto de un algoritmo en una operación, difiriendo algunos pasos a subclases. El método de plantilla permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo.	sí	sí	N / A
Visitante	Representa una operación que se realizará sobre los elementos de una estructura de objeto. Visitor permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.	sí	No	N / A

Patrones de concurrencia

Nombre	Descripción	En POSA2 [22]	Otro
Objeto activo	Desacopla la ejecución del método de la invocación del método que reside en su propio hilo de control. El objetivo es introducir la simultaneidad mediante el uso de la invocación de métodos asincrónicos y un programador para manejar las solicitudes.	sí	N / A
Balking	Solo ejecute una acción en un objeto cuando el objeto esté en un estado particular.	No	N / A
Propiedades de unión	Combinar múltiples observadores para obligar a que las propiedades en diferentes objetos se sincronicen o coordinen de alguna manera. [23]	No	N / A
Computar kernel	El mismo cálculo muchas veces en paralelo, diferenciándose por los parámetros enteros usados ​​con la matemática de puntero no ramificado en arreglos compartidos, como la multiplicación de matrices optimizada por GPU o la red neuronal convolucional .	No	N / A
Bloqueo verificado dos veces	Reduzca la sobrecarga de adquirir un candado probando primero el criterio de bloqueo (la 'sugerencia de candado') de una manera insegura; sólo si tiene éxito, prosigue la lógica de bloqueo real. Puede ser inseguro cuando se implementa en algunas combinaciones de idioma / hardware. Por lo tanto, a veces puede considerarse un antipatrón .	sí	N / A
Asincrónico basado en eventos	Soluciona problemas con el patrón asincrónico que ocurren en programas multiproceso. [24]	No	N / A
Suspensión vigilada	Gestiona operaciones que requieren tanto la adquisición de un bloqueo como una condición previa que debe cumplirse antes de que se pueda ejecutar la operación.	No	N / A
Entrar	Join-pattern proporciona una forma de escribir programas simultáneos, paralelos y distribuidos mediante el paso de mensajes. Comparado con el uso de subprocesos y bloqueos, este es un modelo de programación de alto nivel.	No	N / A
Cerrar con llave	Un hilo pone un "bloqueo" en un recurso, evitando que otros hilos accedan a él o lo modifiquen. [25]	No	PoEAA [16]
Patrón de diseño de mensajería (MDP)	Permite el intercambio de información (es decir, mensajes) entre componentes y aplicaciones.	No	N / A
Supervisar objeto	Un objeto cuyos métodos están sujetos a exclusión mutua , evitando así que múltiples objetos intenten erróneamente utilizarlo al mismo tiempo.	sí	N / A
Reactor	Un objeto reactor proporciona una interfaz asincrónica a los recursos que deben manejarse sincrónicamente.	sí	N / A
Bloqueo de lectura y escritura	Permite el acceso de lectura simultáneo a un objeto, pero requiere acceso exclusivo para las operaciones de escritura.	No	N / A
Programador	Controle explícitamente cuándo los subprocesos pueden ejecutar código de un solo subproceso.	No	N / A
Grupo de subprocesos	Se crean varios subprocesos para realizar una serie de tareas, que normalmente se organizan en una cola. Normalmente, hay muchas más tareas que hilos. Puede considerarse un caso especial del patrón de grupo de objetos .	No	N / A
Almacenamiento específico de subprocesos	Memoria estática o "global" local a un hilo.	sí	N / A

Documentación

La documentación de un patrón de diseño describe el contexto en el que se usa el patrón, las fuerzas dentro del contexto que el patrón busca resolver y la solución sugerida. ^[26] No existe un formato estándar único para documentar patrones de diseño. Más bien, los diferentes autores de patrones han utilizado una variedad de formatos diferentes. Sin embargo, según Martin Fowler , ciertas formas de patrones se han vuelto más conocidas que otras y, en consecuencia, se convierten en puntos de partida comunes para nuevos esfuerzos de escritura de patrones. ^[27] Un ejemplo de un formato de documentación de uso común es el utilizado por Erich Gamma , Richard Helm , Ralph Johnson y John Vlissides.en su libro Design Patterns . Contiene las siguientes secciones:

• Nombre y clasificación del patrón: un nombre descriptivo y único que ayuda a identificar y hacer referencia al patrón.
• Intención: una descripción del objetivo detrás del patrón y la razón para usarlo.
• También conocido como: otros nombres para el patrón.
• Motivación (Fuerzas): escenario que consta de un problema y un contexto en el que se puede utilizar este patrón.
• Aplicabilidad: situaciones en las que se puede utilizar este patrón; el contexto del patrón.
• Estructura: una representación gráfica del patrón. Se pueden utilizar diagramas de clases y diagramas de interacción para este propósito.
• Participantes: una lista de las clases y objetos usados ​​en el patrón y sus roles en el diseño.
• Colaboración: una descripción de cómo las clases y los objetos utilizados en el patrón interactúan entre sí.
• Consecuencias: una descripción de los resultados, los efectos secundarios y las compensaciones causadas por el uso del patrón.
• Implementación: una descripción de una implementación del patrón; la solución parte del patrón.
• Código de muestra: una ilustración de cómo se puede utilizar el patrón en un lenguaje de programación.
• Usos conocidos: ejemplos de usos reales del patrón.
• Patrones relacionados: otros patrones que tienen alguna relación con el patrón; discusión de las diferencias entre el patrón y patrones similares.

Crítica

Se ha observado que los patrones de diseño pueden ser solo una señal de que faltan algunas características en un lenguaje de programación dado ( Java o C ++, por ejemplo). Peter Norvig demuestra que 16 de los 23 patrones del libro Design Patterns (que se centra principalmente en C ++) se simplifican o eliminan (a través del soporte de lenguaje directo) en Lisp o Dylan . ^[28] Hannemann y Kiczales hicieron observaciones relacionadas que implementaron varios de los 23 patrones de diseño utilizando un lenguaje de programación orientado a aspectos.(AspectJ) y mostró que las dependencias a nivel de código se eliminaron de las implementaciones de 17 de los 23 patrones de diseño y que la programación orientada a aspectos podría simplificar las implementaciones de patrones de diseño. ^[29] Véase también el ensayo de Paul Graham "La venganza de los nerds". ^[30]

El uso inadecuado de patrones puede aumentar innecesariamente la complejidad. ^[31]

Ver también

• Principio de abstracción
• Esqueleto algorítmico
• Anti-patrón
• Patrón arquitectónico
• Patrón de protocolo canónico
• Patrones de depuración
• Patrón de diseño
• Patrones de diseño distribuidos
• Función de doble oportunidad
• Marco de arquitectura empresarial
• GRASP (diseño orientado a objetos)
• Clase de ayudante
• Modismo en programación
• Patrón de diseño de interacción
• Lista de filosofías de desarrollo de software
• Lista de temas de ingeniería de software
• Lenguaje de patrones
• Teoría de patrones
• Patrones pedagógicos
• Repositorio de patrones de Portland
• Refactorización
• Metodología de desarrollo de software

Referencias

1. Wedyan, Fadi; Abufakher, Somia (1 de febrero de 2020). "Impacto de los patrones de diseño en la calidad del software: una revisión sistemática de la literatura" . Software IET . 14 (1): 1-17. doi : 10.1049 / iet-sen.2018.5446 . ISSN 1751-8806 . 
2. Smith, Reid (octubre de 1987). Panel sobre metodología de diseño . OOPSLA '87 Addendum al Procedimiento. doi : 10.1145 / 62138.62151 . Ward advirtió que no se requiere demasiada programación en lo que él denominó "el alto nivel de magos". Señaló que un "lenguaje de patrones" escrito puede mejorar significativamente la selección y aplicación de abstracciones. Propuso un 'cambio radical en la carga del diseño y la implementación' basando la nueva metodología en una adaptación del trabajo de Christopher Alexander en lenguajes de patrones y que los lenguajes de patrones orientados a la programación desarrollados en Tektronix han ayudado significativamente a sus esfuerzos de desarrollo de software.
3. Beck, Kent ; Cunningham, Ward (septiembre de 1987). Uso de lenguajes de patrones para programas orientados a objetos . Taller OOPSLA '87 sobre Especificación y Diseño para Programación Orientada a Objetos . Consultado el 26 de mayo de 2006 .
4. Baroni, Aline Lúcia; Guéhéneuc, Yann-Gaël; Albin-Amiot, Hervé (junio de 2003). "Formalización de Patrones de Diseño". Nantes : École Nationale Supérieure des Techniques Industrielles et des Mines de Nantes. CiteSeerX 10.1.1.62.6466 . 
5. Obispo, Judith. "Patrones de diseño de C # 3.0: utilice el poder de C # 3.0 para resolver problemas del mundo real" . Libros de C # de O'Reilly Media . Consultado el 15 de mayo de 2012 . Si desea acelerar el desarrollo de sus aplicaciones .NET, está listo para los patrones de diseño de C #: formas elegantes, aceptadas y comprobadas de abordar problemas de programación comunes.
6. Tiako, Pierre F. (31 de marzo de 2009). "Modelado formal y especificación de patrones de diseño mediante RTPA". Aplicaciones de software: conceptos, metodologías, herramientas y aplicaciones: conceptos, metodologías, herramientas y aplicaciones . pag. 636. doi : 10.4018 / 978-1-60566-060-8 . ISBN 9781605660615.
7. Meyer, Bertrand ; Arnout, Karine (julio de 2006). "Componentización: el ejemplo del visitante" (PDF) . Computadora IEEE . 39 (7): 23–30. CiteSeerX 10.1.1.62.6082 . doi : 10.1109 / MC.2006.227 . S2CID 15328522 .   
8. Laakso, Sari A. (16 de septiembre de 2003). "Colección de patrones de diseño de interfaz de usuario" . Universidad de Helsinki, Departamento de Ciencias de la Computación . Consultado el 31 de enero de 2008 .
9. Heer, J .; Agrawala, M. (2006). "Patrones de diseño de software para visualización de información" . Transacciones IEEE sobre visualización y gráficos por computadora . 12 (5): 853–60. CiteSeerX 10.1.1.121.4534 . doi : 10.1109 / TVCG.2006.178 . PMID 17080809 . S2CID 11634997 .   
10. Dougherty, Chad; Sayre, Kirk; Seacord, Robert C .; Svoboda, David; Togashi, Kazuya (2009). Patrones de diseño seguro (PDF) . Instituto de Ingeniería de Software.
11. Garfinkel, Simson L. (2005). Principios y patrones de diseño para sistemas informáticos que son simultáneamente seguros y utilizables (tesis doctoral).
12. "Biblioteca de patrones de diseño de Yahoo!" . Archivado desde el original el 29 de febrero de 2008 . Consultado el 31 de enero de 2008 .
13. "¿Cómo diseñar su modelo de negocio como Lean Startup?" . 2010-01-06 . Consultado el 6 de enero de 2010 .
14. Lenguajes de programación de patrones, actas de conferencias (anual, 1994-) [1]
15. McConnell, Steve (junio de 2004). "Diseño en Construcción". Código completo (2ª ed.). Microsoft Press . pag. 104 . ISBN 978-0-7356-1967-8. Tabla 5.1 Patrones de diseño populares
16. Fowler, Martin (2002). Patrones de arquitectura de aplicaciones empresariales . Addison-Wesley . ISBN 978-0-321-12742-6.
17. C. Martin, Robert (2002). "28. Objeto de extensión" . Desarrollo de software ágil, principios, patrones y prácticas . pag. 408 . ISBN 978-0135974445.
18. Alur, Deepak; Crupi, John; Malks, Dan (2003). Patrones principales de J2EE: mejores prácticas y estrategias de diseño . Prentice Hall . pag. 166. ISBN 978-0-13-142246-9.
19. Fowler, Martin (2002). Patrones de arquitectura de aplicaciones empresariales . Addison-Wesley . pag. 344. ISBN 978-0-321-12742-6.
20. Bloch, Joshua (2008). "Ítem 37: Usar interfaces de marcador para definir tipos" . Eficaz Java (Segunda ed.). Addison-Wesley. pag. 179 . ISBN 978-0-321-35668-0.
21. "Gemelo - un patrón de diseño para modelar herencia múltiple" (PDF) .
22. Schmidt, Douglas C .; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000). Arquitectura de software orientada a patrones, volumen 2: patrones para objetos simultáneos y en red . John Wiley e hijos. ISBN 978-0-471-60695-6.
23. Propiedades de encuadernación
24. Nagel, cristiano; Evjen, Bill; Glynn, Jay; Watson, Karli; Skinner, Morgan (2008). "Patrón asincrónico basado en eventos". Profesional C # 2008 . Wiley. págs. 570–571. ISBN 978-0-470-19137-8.
25. Patrón de bloqueo
26. Gabriel, Dick . "Una definición de patrón" . Archivado desde el original el 9 de febrero de 2007 . Consultado el 6 de marzo de 2007 .
27. Fowler, Martin (1 de agosto de 2006). "Redacción de patrones de software" . Consultado el 6 de marzo de 2007 .
28. Norvig, Peter (1998). Patrones de diseño en lenguajes dinámicos .
29. Hannemann, Jan ; Kiczales, Gregor (2002). Implementación de patrones de diseño en Java y AspectJ . OOPSLA '02. doi : 10.1145 / 582419.582436 .
30. Graham, Paul (2002). La venganza de los nerds . Consultado el 11 de agosto de 2012 .
31. McConnell, Steve (2004). Código completo: manual práctico de construcción de software, segunda edición . pag. 105 .

Otras lecturas

• Alexander, Christopher ; Ishikawa, Sara; Silverstein, Murray; Jacobson, Max; Fiksdahl-King, Ingrid; Ángel, Shlomo (1977). Un lenguaje de patrones: pueblos, edificios, construcción . Nueva York: Oxford University Press. ISBN 978-0-19-501919-3.
• Alur, Deepak; Crupi, John; Malks, Dan (mayo de 2003). Patrones centrales de J2EE: mejores prácticas y estrategias de diseño (2ª ed.). Prentice Hall . ISBN 978-0-13-142246-9.
• Beck, Kent (octubre de 2007). Patrones de implementación . Addison-Wesley . ISBN 978-0-321-41309-3.
• Beck, Kent ; Crocker, R .; Meszaros, G .; Coplien, JO ; Dominick, L .; Paulisch, F .; Vlissides, J. (marzo de 1996). Actas de la 18ª Conferencia Internacional de Ingeniería de Software . págs. 25-30.
• Borchers, Jan (2001). Un enfoque de patrón para el diseño de interacción . John Wiley e hijos . ISBN 978-0-471-49828-5.
• Coplien, James O .; Schmidt, Douglas C. (1995). Lenguajes de patrones de diseño de programas . Addison-Wesley . ISBN 978-0-201-60734-5.
• Coplien, James O .; Vlissides, John M .; Kerth, Norman L. (1996). Lenguajes de patrones de diseño de programas 2 . Addison-Wesley . ISBN 978-0-201-89527-8.
• Eloranta, Veli-Pekka; Koskinen, Johannes; Leppänen, Marko; Reijonen, Ville (2014). Diseño de sistemas de control distribuido: un enfoque de lenguaje de patrones . Wiley. ISBN 978-1118694152.
• Fowler, Martin (1997). Patrones de análisis: modelos de objetos reutilizables . Addison-Wesley . ISBN 978-0-201-89542-1.
• Fowler, Martin (2003). Patrones de arquitectura de aplicaciones empresariales . Addison-Wesley . ISBN 978-0-321-12742-6.
• Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy ; Bates, Bert (2004). Patrones de diseño de Head First . O'Reilly Media . ISBN 978-0-596-00712-6.
• Hohmann, Luke; Fowler, Martin; Kawasaki, Guy (2003). Más allá de la arquitectura de software . Addison-Wesley . ISBN 978-0-201-77594-5.
• Gabriel, Richard (1996). Patrones de software: Historias de la comunidad de software (PDF) . Prensa de la Universidad de Oxford . pag. 235. ISBN 978-0-19-512123-0. Archivado desde el original (PDF) el 2003-08-01.
• Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John (1995). Patrones de diseño: elementos de software orientado a objetos reutilizable . Addison-Wesley . ISBN 978-0-201-63361-0.
• Hohpe, Gregor; Woolf, Bobby (2003). Patrones de integración empresarial: diseño, creación e implementación de soluciones de mensajería . Addison-Wesley . ISBN 978-0-321-20068-6.
• Holub, Allen (2004). Holub sobre patrones . Presione . ISBN 978-1-59059-388-2.
• Kircher, Michael; Völter, Markus; Zdun, Uwe (2005). Patrones de comunicación remota: fundamentos del middleware de objetos distribuidos en tiempo real, Internet y empresas . John Wiley e hijos . ISBN 978-0-470-85662-8.
• Larman, Craig (2005). Aplicación de patrones y UML . Prentice Hall . ISBN 978-0-13-148906-6.
• Liskov, Barbara ; Guttag, John (2000). Desarrollo de programas en Java: abstracción, especificación y diseño orientado a objetos . Addison-Wesley . ISBN 978-0-201-65768-5.
• Manolescu, Dragos; Voelter, Markus; Noble, James (2006). Lenguajes de patrones de diseño de programas 5 . Addison-Wesley . ISBN 978-0-321-32194-7.
• Marinescu, Floyd (2002). Patrones de diseño de EJB: patrones, procesos y modismos avanzados . John Wiley e hijos . ISBN 978-0-471-20831-0.
• Martin, Robert Cecil ; Riehle, Dirk; Buschmann, Frank (1997). Lenguajes de patrones de diseño de programas 3 . Addison-Wesley . ISBN 978-0-201-31011-5.
• Mattson, Timothy G; Sanders, Beverly A .; Massingill, Berna L. (2005). Patrones para programación paralela . Addison-Wesley. ISBN 978-0-321-22811-6.
• Shalloway, Alan; Trott, James R. (2001). Explicación de los patrones de diseño, segunda edición: una nueva perspectiva sobre el diseño orientado a objetos . Addison-Wesley. ISBN 978-0-321-24714-8.
• Vlissides, John M. (1998). Tramado de patrones: patrones de diseño aplicados . Addison-Wesley . ISBN 978-0-201-43293-0.
• Weir, Charles; Noble, James (2000). Software de memoria pequeña: patrones para sistemas con memoria limitada . Addison-Wesley . ISBN 978-0-201-59607-6. Archivado desde el original el 17 de junio de 2007.