Patrones de diseño

Es posible que este artículo necesite una reorganización para cumplir con las pautas de diseño de Wikipedia . Por favor, colabore editando el artículo para realizar mejoras en la estructura general. ( Julio de 2013 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Patrones de diseño:
elementos reutilizablesOrientado a objetosSoftware

Autor	Erich Gamma Richard Helm Ralph Johnson Juan Vlissides
Sujeto	Patrones de diseño , ingeniería de software , programación orientada a objetos
Editor	Addison Wesley
Fecha de publicación	1994
Lugar de publicación	Estados Unidos
Páginas	395
ISBN	0-201-63361-2
OCLC	31171684
Decimal Dewey	005.1/2 20
Clase LC	QA76.64.D47 1995

Design Patterns: Elements of Reutilizable Object-Oriented Software (1994) es unlibro de ingeniería de software que describe patrones de diseño de software . El libro fue escrito por Erich Gamma , Richard Helm , Ralph Johnson y John Vlissides , con un prólogo de Grady Booch . El libro está dividido en dos partes, con los dos primeros capítulos explorando las capacidades y las dificultades de la programación orientada a objetos, y los capítulos restantes describiendo 23 patrones de diseño de software clásicos . El libro incluye ejemplos en C++ y Smalltalk .

Ha sido influyente en el campo de la ingeniería de software y se considera una fuente importante para la teoría y la práctica del diseño orientado a objetos. Se han vendido más de 500.000 copias en inglés y en otros 13 idiomas. ^[1] A los autores se les suele llamar la Banda de los Cuatro (GoF). ^{[2] [3] [4] [5]}

El libro comenzó en una sesión informal en la reunión de la OOPSLA de 1990 , "Hacia un manual de arquitectura", donde Erich Gamma y Richard Helm se conocieron y descubrieron su interés común. Más tarde se les unieron Ralph Johnson y John Vlissides. ^[6] El libro se publicó originalmente el 21 de octubre de 1994, con derechos de autor de 1995, y se puso a disposición del público en la reunión de la OOPSLA de 1994.

This section may contain an excessive amount of intricate detail that may interest only a particular audience. Please help by spinning off or relocating any relevant information, and removing excessive detail that may be against Wikipedia's inclusion policy. (October 2020) (Learn how and when to remove this message)

El capítulo 1 es un análisis de las técnicas de diseño orientado a objetos , basadas en la experiencia de los autores, que creen que conducirían a un buen diseño de software orientado a objetos, incluyendo:

• "Programa para una interfaz, no para una implementación" (Gang of Four 1995:18)
• Composición por encima de herencia : “Priorizar la ' composición de objetos ' por encima de la ' herencia de clases '” (Gang of Four 1995:20)

Los autores afirman las siguientes ventajas de las interfaces sobre la implementación:

• Los clientes no conocen los tipos específicos de objetos que utilizan, siempre que el objeto se adhiera a la interfaz.
• Los clientes desconocen las clases que implementan estos objetos; los clientes solo conocen las clases abstractas que definen la interfaz.

El uso de una interfaz también conduce a la vinculación dinámica y al polimorfismo , que son características centrales de la programación orientada a objetos.

Los autores se refieren a la herencia como reutilización de caja blanca , donde caja blanca hace referencia a la visibilidad, porque los detalles internos de las clases padre suelen ser visibles para las subclases . Por el contrario, los autores se refieren a la composición de objetos (en la que los objetos con interfaces bien definidas se utilizan dinámicamente en tiempo de ejecución por objetos que obtienen referencias a otros objetos) como reutilización de caja negra porque no es necesario que los detalles internos de los objetos compuestos sean visibles en el código que los utiliza.

Los autores analizan en profundidad la tensión entre la herencia y la encapsulación y afirman que, según su experiencia, los diseñadores abusan de la herencia (Gang of Four 1995:20). El peligro se indica de la siguiente manera:

"Dado que la herencia expone una subclase a los detalles de la implementación de su padre, a menudo se dice que 'la herencia rompe la encapsulación'". (Gang of Four 1995:19)

Advierten que la implementación de una subclase puede llegar a estar tan ligada a la implementación de su clase padre que cualquier cambio en la implementación de la clase padre obligará a la subclase a cambiar. Además, afirman que una forma de evitar esto es heredar solo de clases abstractas, pero luego señalan que hay una reutilización mínima del código.

Se recomienda usar la herencia principalmente cuando se aumenta la funcionalidad de componentes existentes, se reutiliza la mayor parte del código antiguo y se agregan cantidades relativamente pequeñas de código nuevo.

Para los autores, la "delegación" es una forma extrema de composición de objetos que siempre se puede utilizar para reemplazar la herencia. La delegación involucra dos objetos: un "emisor" se pasa a sí mismo a un "delegado" para permitir que el delegado haga referencia al remitente. Por lo tanto, el vínculo entre dos partes de un sistema se establece solo en tiempo de ejecución, no en tiempo de compilación. El artículo Callback tiene más información sobre la delegación.

Los autores también analizan los llamados tipos parametrizados, que también se conocen como genéricos ( Ada , Eiffel , Java , C# , Visual Basic (.NET) y Delphi ) o plantillas ( C++ ). Estos permiten definir cualquier tipo sin especificar todos los demás tipos que utiliza; los tipos no especificados se suministran como "parámetros" en el punto de uso.

Los autores admiten que la delegación y la parametrización son muy poderosas, pero añaden una advertencia:

"El software dinámico y altamente parametrizado es más difícil de entender y construir que el software más estático" (Gang of Four 1995:21)

Los autores distinguen además entre " agregación ", donde un objeto "tiene" o "es parte" de otro objeto (lo que implica que un objeto agregado y su propietario tienen tiempos de vida idénticos) y conocimiento, donde un objeto simplemente "sabe de" otro objeto. A veces, el conocimiento se denomina "asociación" o relación de "uso". Los objetos de conocimiento pueden solicitar operaciones entre sí, pero no son responsables entre sí. El conocimiento es una relación más débil que la agregación y sugiere un acoplamiento mucho más flexible entre objetos, lo que a menudo puede ser deseable para lograr la máxima capacidad de mantenimiento en los diseños.

Los autores emplean el término "kit de herramientas" donde otros podrían utilizar hoy "biblioteca de clases", como en C# o Java. En su lenguaje, los kits de herramientas son el equivalente orientado a objetos de las bibliotecas de subrutinas, mientras que un " marco " es un conjunto de clases cooperantes que conforman un diseño reutilizable para una clase específica de software. Afirman que las aplicaciones son difíciles de diseñar, los kits de herramientas son más difíciles y los marcos son los más difíciles de diseñar.

Los patrones de creación son aquellos que crean objetos, en lugar de tener que instanciarlos directamente. Esto le da al programa más flexibilidad para decidir qué objetos deben crearse para un caso determinado.

• Los grupos de fábricas abstractas agrupan fábricas de objetos que tienen un tema común.
• Builder construye objetos complejos separando la construcción y la representación.
• El método de fábrica crea objetos sin especificar la clase exacta a crear.
• Prototype crea objetos clonando un objeto existente.
• Singleton restringe la creación de objetos para una clase a una sola instancia.

Los patrones estructurales se ocupan de la composición de clases y objetos. Utilizan la herencia para componer interfaces y definir formas de componer objetos para obtener nuevas funciones.

• El adaptador permite que las clases con interfaces incompatibles trabajen juntas envolviendo su propia interfaz alrededor de la de una clase ya existente.
• Bridge desacopla una abstracción de su implementación para que ambas puedan variar independientemente.
• Compuesto compone cero o más objetos similares para que puedan manipularse como un solo objeto.
• El decorador agrega/anula dinámicamente el comportamiento de un método existente de un objeto.
• Facade proporciona una interfaz simplificada para un gran cuerpo de código.
• Flyweight reduce el costo de crear y manipular una gran cantidad de objetos similares.
• El proxy proporciona un marcador de posición para otro objeto para controlar el acceso, reducir costos y reducir la complejidad.

La mayoría de los patrones de diseño de comportamiento se ocupan específicamente de la comunicación entre objetos.

• La cadena de responsabilidad delega comandos a una cadena de objetos de procesamiento.
• El comando crea objetos que encapsulan acciones y parámetros.
• El intérprete implementa un lenguaje especializado.
• El iterador accede a los elementos de un objeto secuencialmente sin exponer su representación subyacente.
• Mediator permite un acoplamiento flexible entre clases al ser la única clase que tiene conocimiento detallado de sus métodos.
• Memento proporciona la capacidad de restaurar un objeto a su estado anterior (deshacer).
• Observer es un patrón de publicación/suscripción que permite que varios objetos observadores vean un evento.
• El estado permite que un objeto altere su comportamiento cuando cambia su estado interno.
• La estrategia permite seleccionar uno de una familia de algoritmos sobre la marcha en tiempo de ejecución.
• El método de plantilla define el esqueleto de un algoritmo como una clase abstracta, permitiendo que sus subclases proporcionen un comportamiento concreto.
• Visitor separa un algoritmo de una estructura de objeto moviendo la jerarquía de métodos a un objeto.

En 2005, la ACM SIGPLAN otorgó el Premio al Logro en Lenguajes de Programación de ese año a los autores, en reconocimiento al impacto de su trabajo "en la práctica de la programación y el diseño de lenguajes de programación ". ^[7]

Se ha criticado el concepto de patrones de diseño de software en general y los patrones de diseño en particular. Una crítica principal a los patrones de diseño es que son simplemente soluciones alternativas a las características faltantes en C++, reemplazando características abstractas elegantes con patrones concretos extensos, convirtiéndose esencialmente en un "compilador humano". Paul Graham escribió: ^[8]

Cuando veo patrones en mis programas, lo considero un signo de problemas. La forma de un programa debería reflejar únicamente el problema que necesita resolver. Cualquier otra regularidad en el código es una señal, al menos para mí, de que estoy usando abstracciones que no son lo suficientemente potentes; a menudo, de que estoy generando a mano las expansiones de alguna macro que necesito escribir.

Peter Norvig demuestra que 16 de los 23 patrones en Design Patterns son simplificados o eliminados por las características del lenguaje en Lisp o Dylan . ^{[9] Hannemann y} Kiczales hicieron 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. ^[10]

En una entrevista con InformIT en 2009, Erich Gamma afirmó que los autores del libro habían tenido una discusión en 2005 sobre cómo habrían refactorizado el libro y llegaron a la conclusión de que habrían recategorizado algunos patrones y añadido algunos más, como objeto/interfaz de extensión, inyección de dependencia, objeto de tipo y objeto nulo. Gamma quería eliminar el patrón Singleton, pero no hubo consenso entre los autores para hacerlo. ^[11]

• Patrón de diseño de software
• Patrones de integración empresarial
• GRASP (diseño orientado a objetos)
• Patrones pedagógicos