stringtranslate.com

Patrón de diseño de software

En ingeniería de software , un patrón de diseño describe un aspecto relativamente pequeño y bien definido (es decir, la funcionalidad) de un programa de computadora en términos de cómo escribir el código .

El uso de un patrón tiene como objetivo aprovechar un concepto existente en lugar de reinventarlo . Esto puede reducir el tiempo de desarrollo del software y aumentar la calidad del programa resultante.

Cabe destacar que un patrón no consiste en un artefacto de software . La mayoría de los recursos de desarrollo que utiliza un programador implican la configuración de la base de código para utilizar un artefacto; por ejemplo, una biblioteca . Por el contrario, para utilizar un patrón, un programador escribe código tal como lo describe el patrón. El resultado es único cada vez, aunque pueda reconocerse como basado en el patrón.

Algunos consideran que el uso de patrones es la mejor práctica para el diseño de software . Otros consideran que el uso de patrones de diseño es un enfoque estructurado para la programación informática .

Conceptualmente, el patrón de diseño puede describirse como más específico que el paradigma de programación y menos específico que el algoritmo .

Historia

Los patrones se originaron como un concepto arquitectónico por Christopher Alexander en 1977 en A Pattern Language (véase su artículo, "The Pattern of Streets", JOURNAL OF THE AIP, septiembre de 1966, vol. 32, n.º 5, págs. 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. [1] [2] En los años siguientes, Beck, Cunningham y otros continuaron con este trabajo.

Los patrones de diseño ganaron popularidad en la informática después de que en 1994 se publicara el libro Design Patterns: Elements of Reutilizable Object-Oriented Software, obra de la denominada "Banda de los Cuatro" (Gamma et al.), que suele abreviarse como "GoF". Ese mismo año se celebró la primera Conferencia de Lenguajes de Patrones de Programación y al año siguiente se creó el Repositorio de Patrones de Portland para documentar los patrones de diseño. El alcance del término sigue siendo motivo de controversia. Entre los libros más destacados del género de los patrones de diseño se incluyen:

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. [3]

Práctica

Los patrones de diseño pueden acelerar el proceso de desarrollo al proporcionar paradigmas de desarrollo probados. [4] Un diseño de software eficaz requiere tener en cuenta cuestiones que pueden no hacerse evidentes hasta más adelante en la implementación. El código recién escrito a menudo puede tener problemas ocultos y sutiles que tardan en detectarse; problemas que a veces pueden causar problemas importantes en el futuro. La reutilización de patrones de diseño puede ayudar a prevenir dichos problemas [5] y mejorar la legibilidad del código para quienes están familiarizados con los patrones.

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 proporcionan soluciones generales, documentadas en un formato que no requiere detalles vinculados a un problema particular.

En 1996, Christopher Alexander fue invitado a dar un discurso de apertura en la Convención OOPSLA de 1996. Allí reflexionó sobre cómo había evolucionado su trabajo sobre patrones en la arquitectura y sus esperanzas sobre cómo la comunidad de diseño de software podría ayudar a la arquitectura a extender los patrones para crear estructuras vivas que utilicen esquemas generativos que se parezcan más al código informático.

Motivo

Un patrón describe un motivo de diseño , también conocido como microarquitectura prototípica , como un conjunto de componentes del programa (por ejemplo, clases, métodos...) y sus relaciones. Un desarrollador adapta el motivo a su base de código para resolver el problema descrito por el patrón. El código resultante tiene una estructura y una organización similares al motivo elegido.

Patrones específicos del dominio

También se han hecho esfuerzos para codificar patrones de diseño en dominios particulares, incluyendo 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 , [6] visualización de información , [7] diseño seguro, [8] "usabilidad segura", [9] diseño web [10] y diseño de modelos de negocios. [11]

Las actas anuales de la Conferencia sobre lenguajes de patrones de programación [12] incluyen muchos ejemplos de patrones específicos del dominio.

Programación orientada a objetos

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

Ejemplos

Los patrones de diseño se pueden organizar en grupos según el tipo de problema que resuelven. Los patrones de creación crean objetos. Los patrones estructurales organizan clases y objetos para formar estructuras más grandes que brindan nuevas funciones. Los patrones de comportamiento brindan comunicación entre objetos y la realización de estos patrones.

Patrones de creación

Patrones estructurales

Patrones de comportamiento

Patrones de concurrencia

Documentación

La documentación de un patrón de diseño describe el contexto en el que se utiliza el patrón, las fuerzas dentro del contexto que el patrón busca resolver y la solución sugerida. [25] No existe un formato único y estándar para documentar patrones de diseño. Más bien, 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 han convertido en puntos de partida comunes para nuevos esfuerzos de escritura de patrones. [26] Un ejemplo de un formato de documentación comúnmente utilizado es el utilizado por Erich Gamma , Richard Helm , Ralph Johnson y John Vlissides en su libro Design Patterns . Contiene las siguientes secciones:

Crítica

Algunos sugieren que los patrones de diseño pueden ser una señal de que faltan características en un lenguaje de programación determinado ( 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 directo del lenguaje) en Lisp o Dylan . [27] Hannemann y Kiczales realizaron observaciones relacionadas, implementaron varios de los 23 patrones de diseño utilizando un lenguaje de programación orientado a aspectos (AspectJ) y demostraron 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. [28] Véase también el ensayo de Paul Graham "Revenge of the Nerds". [29]

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

Por definición, un patrón debe programarse de nuevo en cada aplicación que lo utilice. Dado que algunos autores consideran que esto supone un paso atrás con respecto a la reutilización de software que ofrecen los componentes , los investigadores han trabajado para convertir los patrones en componentes. Meyer y Arnout pudieron proporcionar la componentización total o parcial de dos tercios de los patrones que intentaron. [31]

Para lograr flexibilidad, los patrones de diseño pueden introducir niveles adicionales de indirección , lo que puede complicar el diseño resultante y disminuir el rendimiento en tiempo de ejecución .

Véase también

Referencias

  1. ^ Smith, Reid (octubre de 1987). Panel on design methodology . OOPSLA '87 Addendum to the Proceedings. doi :10.1145/62138.62151. Ward advirtió contra la necesidad de exigir demasiada programación en lo que él llamó "el alto nivel de los 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.
  2. ^ 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 .
  3. ^ Baroni, Aline Lucía; Guéhéneuc, Yann-Gaël; Albin-Amiot, Hervé (junio de 2003). Formalización de patrones de diseño (Reporte). Informe técnico de la REM. Nantes : Escuela Nacional Superior de Técnicas Industriales y Minas de Nantes. CiteSeerX 10.1.1.62.6466 . S2CID  624834 – vía ResearchGate. 
  4. ^ Bishop, Judith. "Patrones de diseño de C# 3.0: use 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 probadas de abordar problemas de programación comunes.
  5. ^ Tiako, Pierre F. (31 de marzo de 2009). "Modelado formal y especificación de patrones de diseño utilizando RTPA". En Tiako, Pierre F (ed.). Aplicaciones de software: conceptos, metodologías, herramientas y aplicaciones: Conceptos, metodologías, herramientas y aplicaciones . p. 636. doi :10.4018/978-1-60566-060-8. ISBN 9781605660615.
  6. ^ 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 .
  7. ^ Heer, J.; Agrawala, M. (2006). "Patrones de diseño de software para visualización de información". IEEE Transactions on Visualization and Computer Graphics . 12 (5): 853–60. CiteSeerX 10.1.1.121.4534 . doi :10.1109/TVCG.2006.178. PMID  17080809. S2CID  11634997. 
  8. ^ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (2009). Patrones de diseño seguros (PDF) . Instituto de Ingeniería de Software.
  9. ^ Garfinkel, Simson L. (2005). Principios y patrones de diseño para sistemas informáticos que sean simultáneamente seguros y utilizables (tesis doctoral).
  10. ^ "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 .
  11. ^ "¿Cómo diseñar tu modelo de negocio como una Lean Startup?". 2010-01-06 . Consultado el 2010-01-06 .
  12. ^ Lenguajes de patrones de programación, Actas de congresos (anuales, 1994—) [1]
  13. ^ abc McConnell, Steve (junio de 2004). "Diseño en construcción". Code Complete (2.ª ed.). Microsoft Press . pág. 104. ISBN 978-0-7356-1967-8Tabla 5.1 Patrones de diseño populares
  14. ^ ab Fowler, Martin (2002). Patrones de arquitectura de aplicaciones empresariales. Addison-Wesley . ISBN 978-0-321-12742-6.
  15. ^ Alur, Deepak; Crupi, John; Malks, Dan (2003). Patrones básicos de J2EE: mejores prácticas y estrategias de diseño. Prentice Hall . p. 166. ISBN 978-0-13-142246-9.
  16. ^ Fowler, Martin (2002). Patrones de arquitectura de aplicaciones empresariales. Addison-Wesley . p. 344. ISBN 978-0-321-12742-6.
  17. ^ Bloch, Joshua (2008). "Ítem 37: Utilizar interfaces de marcadores para definir tipos". Effective Java (Segunda edición). Addison-Wesley. pág. 179. ISBN 978-0-321-35668-0.
  18. ^ "Twin: un patrón de diseño para modelar herencia múltiple" (PDF) .
  19. ^ Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000). Arquitectura de software orientada a patrones, volumen 2: Patrones para objetos concurrentes y en red . John Wiley & Sons. ISBN 978-0-471-60695-6.
  20. ^ Propiedades de encuadernación
  21. ^ Nagel, Christian; Evjen, Bill; Glynn, Jay; Watson, Karli; Skinner, Morgan (2008). "Patrón asincrónico basado en eventos". Professional C# 2008 . Wiley. págs. 570–571. ISBN 978-0-470-19137-8.
  22. ^ Patrón de bloqueo
  23. ^ Francalanza, Adrian; Tabone, Gerard (octubre de 2023). "ElixirST: Un sistema de tipos basado en sesiones para módulos Elixir". Revista de métodos lógicos y algebraicos en programación . 135 . doi :10.1016/j.jlamp.2023.100891. S2CID  251442539.
  24. ^ Schmidt, Douglas C.; Vinoski, Steve (julio-agosto de 1996). "Interconexiones de objetos: comparación de técnicas de programación alternativas para servidores CORBA multiproceso (columna 7)" (PDF) . Informe SIGS C++ . S2CID  2654843.
  25. ^ 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 .
  26. ^ Fowler, Martin (1 de agosto de 2006). "Writing Software Patterns" (Cómo escribir patrones de software) . Consultado el 6 de marzo de 2007 .
  27. ^ Norvig, Peter (1998). Patrones de diseño en lenguajes dinámicos.
  28. ^ Hannemann, Jan; Kiczales, Gregor (2002). "Implementación de patrones de diseño en Java y AspectJ". Actas de la 17.ª conferencia ACM SIGPLAN sobre programación orientada a objetos, sistemas, lenguajes y aplicaciones - OOPSLA '02 . OOPSLA '02. p. 161. doi :10.1145/582419.582436. ISBN 1581134711.
  29. ^ Graham, Paul (2002). "La venganza de los nerds" . Consultado el 11 de agosto de 2012 .
  30. ^ McConnell, Steve (2004). Code Complete: A Practical Handbook of Software Construction, 2.ª edición . Pearson Education. pág. 105. ISBN 9780735619678.
  31. ^ Meyer, Bertrand ; Arnout, Karine (julio de 2006). "Componentización: el ejemplo del visitante" (PDF) . IEEE Computer . 39 (7): 23–30. CiteSeerX 10.1.1.62.6082 . doi :10.1109/MC.2006.227. S2CID  15328522. 

Lectura adicional