Patrón de diseño de software

Un patrón de diseño de software describe una solución reutilizable para un comportamiento comúnmente necesario en el software . ^{[ 1 ]} Un patrón de diseño no es una estructura rígida que se copie directamente en el código fuente . Más bien, es una descripción y una plantilla para resolver un tipo particular de problema que se puede utilizar en muchos contextos diferentes, incluidos distintos lenguajes de programación y plataformas informáticas . ^{[ 2 ]} Los patrones de diseño pueden considerarse como buenas prácticas formalizadas que el programador puede utilizar para resolver problemas comunes al diseñar software.

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 intervienen. Los patrones que implican estado mutable pueden no ser adecuados para lenguajes de programación funcional . Algunos patrones pueden resultar innecesarios en lenguajes que cuentan con soporte integrado para resolver el problema que intentan solucionar, y los patrones orientados a objetos no son necesariamente adecuados para lenguajes no orientados a objetos. ^{[ 3 ]}

Los patrones se originaron como un concepto arquitectónico por Christopher Alexander ya en 1977 en A Pattern Language (cf. 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 a los lenguajes de patrones , y presentaron sus resultados en la conferencia OOPSLA de ese año. ^{[ 4 ] [ 5 ]} En los años siguientes, Beck, Cunningham y otros dieron seguimiento a este trabajo.

Los patrones de diseño ganaron popularidad en la informática tras la publicación en 1994 del libro Design Patterns: Elements of Reusable Object-Oriented Software por el llamado "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides), a menudo abreviado como "GoF". ^{[ 6 ]} Ese mismo año se celebró la primera Pattern Languages ​​of Programming Conference, y al año siguiente se creó el Portland Pattern Repository para la documentación de patrones de diseño.

Although design patterns have been applied practically for a long time, formalization of the concept of design patterns languished for several years.^[7]

Design patterns can speed up the development process by providing proven development paradigms.^[8] Effective software design requires considering issues that may not become apparent until later in the implementation. Freshly written code can often have hidden, subtle issues that take time to be detected – issues that sometimes can cause major problems down the road. Reusing design patterns can help to prevent such issues,^[9] and enhance code readability for those familiar with the patterns.

Software design techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that does not require specifics tied to a particular problem.^[10]

In 1996, Christopher Alexander was invited to give a Keynote Speech to the 1996 OOPSLA Convention. Here he reflected on how his work on Patterns in Architecture had developed and his hopes for how the Software Design community could help Architecture extend Patterns to create living structures that use generative schemes that are more like computer code.

A pattern describes a design motif, also known as a prototypical micro-architecture, as a set of program constituents (e.g., classes, methods...) and their relationships. A developer adapts the motif to their codebase to solve the problem described by the pattern. The resulting code has structure and organization similar to the chosen motif.

Efforts have also been made to codify design patterns in particular domains, including the use of existing design patterns as well as domain-specific design patterns. Examples include user interface design patterns,^[11]information visualization,^[12] secure design,^[13] "secure usability",^[14]web design^[15] and business model design.^[16]

The annual Pattern Languages of Programming Conference proceedings include many examples of domain-specific patterns.^[17]

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

Los patrones de diseño se pueden organizar en grupos según el tipo de problema que resuelven.

La documentación de un patrón de diseño describe el contexto en el que se utiliza, las fuerzas dentro de ese contexto que el patrón busca resolver y la solución sugerida. ^{[ 31 ]} No existe un formato único y estándar para documentar patrones de diseño. En cambio, diferentes autores de patrones han utilizado diversos formatos. 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. ^{[ 32 ]} 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

Un nombre descriptivo y único que ayuda a identificar y referirse al patrón.

Intención

Una descripción del objetivo que subyace al patrón y la razón para utilizarlo.

También conocido como

Otros nombres para el patrón.

Motivación

Un escenario que consta de un problema y un contexto en el que se puede utilizar este patrón.

Aplicabilidad

Situaciones en las que este patrón es utilizable; el contexto para el uso del patrón.

Estructura

Representación gráfica del patrón. Para ello, se pueden utilizar diagramas de clases y diagramas de interacción .

Participantes

Una lista de las clases y objetos utilizados en el patrón y sus funciones en el diseño.

Colaboración

Una descripción de cómo interactúan entre sí las clases y los objetos utilizados en el patrón.

Consecuencias

Una descripción de los resultados, los efectos secundarios y las ventajas e inconvenientes derivados del uso de este patrón.

Implementación

Una descripción de una implementación del patrón; la parte de la solución del patrón.

Código de ejemplo

Un ejemplo de cómo se puede utilizar este patrón en un lenguaje de programación.

Usos conocidos

Ejemplos de usos reales del patrón.

Patrones relacionados

Otros patrones que guardan alguna relación con el patrón; análisis de las diferencias entre el patrón y patrones similares.

Algunos sugieren que la necesidad de un patrón de diseño puede ser un indicio de que falta una característica en un lenguaje de programación. Peter Norvig demuestra que 16 de los 23 patrones del libro Design Patterns (que se centra principalmente en C++) se simplifican o eliminan (mediante soporte directo del lenguaje) en Lisp o Dylan . ^{[ 33 ]} Hannemann y Kiczales (2002) hicieron observaciones similares al implementar varios de los 23 patrones de diseño utilizando un lenguaje de programación orientado a aspectos (AspectJ) y demostraron que se eliminaron las dependencias a nivel de código 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. ^{[ 34 ]} Véase también el ensayo de Paul Graham «La venganza de los nerds». ^{[ 35 ]}

El uso inapropiado de patrones puede aumentar innecesariamente la complejidad. ^{[ 36 ]}

Por definición, un patrón debe programarse de nuevo en cada aplicación que lo utilice. ^{[ 37 ]} Dado que algunos autores consideran esto un retroceso respecto a la reutilización de software proporcionada por los componentes , los investigadores han trabajado para utilizar herramientas de programación genérica para convertir patrones en componentes, en un proceso denominado componentización . ^{[ 38 ] [ 39 ]} Meyer y Arnout (2006) lograron proporcionar componentización total o parcial de dos tercios de los patrones que intentaron. ^{[ 40 ]}

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 .

Los siguientes conceptos son similares en su naturaleza general, pero difieren de los patrones de diseño de software: ^{[ 41 ] [ 42 ] [ 19 ] [ 43 ]}

Patrón de arquitectura de software

Una solución reutilizable y probada para un problema recurrente a nivel de sistema, que aborda preocupaciones relacionadas con la estructura general, las interacciones de los componentes y los atributos de calidad del sistema. ^{[ 44 ]} Los patrones de arquitectura de software operan en un nivel de abstracción superior al de los patrones de diseño, resolviendo desafíos más amplios a nivel de sistema. Si bien estos patrones suelen afectar las preocupaciones a nivel de sistema, la distinción entre patrones arquitectónicos y estilos arquitectónicos a veces puede ser difusa. Ejemplos incluyen Circuit Breaker . ^{[ 41 ] [ 42 ] [ 19 ]}

Estilo de arquitectura de software

Una organización estructural de alto nivel que define la organización general del sistema, especificando cómo se organizan los componentes, cómo interactúan y las restricciones sobre esas interacciones. Los estilos de arquitectura suelen incluir un vocabulario de tipos de componentes y conectores, así como modelos semánticos para interpretar las propiedades del sistema. Estos estilos representan el nivel más general de organización del sistema. Algunos ejemplos son la arquitectura en capas , los microservicios y la arquitectura orientada a eventos . ^{[ 41 ] [ 42 ] [ 19 ]}

Patrón de implementación

Beck distingue entre patrones de diseño, que generalmente describen las relaciones entre clases, y patrones de implementación , que a menudo se limitan a una sola clase. ^{[ 45 ]} Partiendo de esto, Iglberger (2022) define un patrón de implementación como un modismo de programación que no introduce una abstracción y, por lo tanto, reside en el nivel de los detalles de implementación. ^{[ 46 ]} Por esta razón, suelen ser específicos del lenguaje de implementación, con copy-and-swap y RAII como ejemplos en C++, ^{[ 43 ]} aunque en otros lenguajes, tales modismos pueden constituir verdaderos patrones de diseño. ^{[ 47 ]}