Design Patterns: Elements of Reusable Object-Oriented Software (1994) es unlibro de ingeniería de software que describe los 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, los dos primeros capítulos exploran las capacidades y las trampas de la programación orientada a objetos, y los capítulos restantes describen 23 patrones clásicos de diseño de software . El libro incluye ejemplos en C ++ y Smalltalk .
Autor | La "banda de los cuatro":
|
---|---|
País | Estados Unidos |
Sujeto | Patrones de diseño , ingeniería de software , programación orientada a objetos |
Editor | Addison-Wesley |
Fecha de publicación | 1994 |
Paginas | 395 |
ISBN | 0-201-63361-2 |
OCLC | 31171684 |
Decimal Dewey | 005.1 / 2 20 |
Clase LC | QA76.64 .D47 1995 |
Ha influido 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. A los autores a menudo se les conoce como la Banda de los Cuatro ( GoF ). [1]
Historia
El libro comenzó en una sesión de pájaros de una pluma (BoF) en OOPSLA '90, "Towards an Architecture Handbook", dirigido por Bruce Anderson, 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. [2] La fecha de publicación original del libro fue el 21 de octubre de 1994 con un copyright de 1995, por lo que a menudo se cita con un año de 1995, a pesar de haber sido publicado en 1994. El libro se puso a disposición del público por primera vez en la reunión de OOPSLA. celebrada en Portland, Oregon, en octubre de 1994. En 2005, el ACM SIGPLAN otorgó el Premio al Logro de 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". [3] En marzo de 2012, el libro estaba en su cuadragésima edición.
Introducción
El Capítulo 1 es una discusión 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, que incluye:
- "Programa a una interfaz, no a una implementación". (Banda de cuatro 1995: 18)
- Composición sobre herencia : "Favorece la ' composición de objetos ' sobre la ' herencia de clases '". (Banda de cuatro 1995: 20)
Los autores afirman lo siguiente como ventajas de las interfaces sobre la implementación:
- los clientes desconocen 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 un enlace dinámico y 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, y la caja blanca se refiere a la visibilidad, porque las partes internas de las clases principales 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 los 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 estén visibles en el código utilizando ellos.
Los autores discuten extensamente la tensión entre herencia y encapsulación y afirman que, en su experiencia, los diseñadores abusan de la herencia (Gang of Four 1995: 20). El peligro se indica de la siguiente manera:
- "Debido a 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'". (Banda de cuatro 1995: 19)
Advierten que la implementación de una subclase puede estar tan ligada a la implementación de su clase padre que cualquier cambio en la implementación del padre forzará 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 el uso de la herencia principalmente cuando se agrega a la funcionalidad de los 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 implica dos objetos: un 'remitente' se pasa a sí mismo a un 'delegado' para permitir que el delegado se refiera 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 de devolución de llamada tiene más información sobre la delegación.
Los autores también discuten los llamados tipos parametrizados, que también se conocen como genéricos (Ada, Eiffel, Java , C #, VB.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 proporcionan como "parámetros" en el punto de uso.
Los autores admiten que la delegación y la parametrización son muy poderosas, pero agregan 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". (Banda de cuatro 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 vidas idénticas) y conocido, donde un objeto simplemente 'conoce' otro objeto. A veces, al conocido se le llama "asociación" o relación de "uso". Los objetos conocidos 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 una máxima capacidad de mantenimiento en un diseño.
Los autores emplean el término 'kit de herramientas' donde otros podrían usar 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 cooperativas 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.
Patrones por tipo
Creacional
Los patrones de creación son los que crean objetos, en lugar de tener que instanciar objetos directamente. Esto le da al programa más flexibilidad para decidir qué objetos deben crearse para un caso dado.
- Fábrica abstracta agrupa 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.
Estructural
Se refieren a la composición de clases y objetos. Utilizan la herencia para componer interfaces y definir formas de componer objetos para obtener nuevas funcionalidades.
- 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 los dos puedan variar de forma independiente.
- Compuesto compone cero o más objetos similares para que puedan manipularse como un solo objeto.
- Decorator agrega / anula dinámicamente el comportamiento en 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 el costo y reducir la complejidad.
Conductual
La mayoría de estos patrones de diseño se refieren específicamente a la comunicación entre objetos.
- La cadena de responsabilidad delega comandos a una cadena de objetos de procesamiento.
- Command crea objetos que encapsulan acciones y parámetros.
- El intérprete implementa un lenguaje especializado.
- Iterator 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 un 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, lo que permite que sus subclases proporcionen un comportamiento concreto.
- El visitante separa un algoritmo de una estructura de objeto moviendo la jerarquía de métodos a un objeto.
Crítica
Las críticas se han dirigido al concepto de patrones de diseño de software en general, y específicamente a los patrones de diseño . Una crítica principal de Design Patterns es que sus patrones son simplemente soluciones para las características que faltan en C ++, reemplazando elegantes características abstractas con largos patrones concretos, convirtiéndose esencialmente en un "compilador humano" o "generando manualmente las expansiones de alguna macro". Paul Graham escribió: [4]
Cuando veo patrones en mis programas, lo considero una señal de problemas. La forma de un programa debe reflejar solo 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 poderosas, a menudo 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 . [5] 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 mostraron 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 la implementación de patrones de diseño. [6]
También ha habido críticas humorísticas, como un juicio espectáculo en OOPSLA '99 el 3 de noviembre de 1999, [7] [8] [a] y una parodia del formato, por Jim Coplien , titulado " Kansas City Air Conditioner ".
En una entrevista con InformIT en 2009, Erich Gamma declaró que los autores del libro tuvieron una discusión en 2005 sobre cómo habrían refactorizado el libro y concluyeron que habrían recategorizado algunos patrones y agregado algunos adicionales. Gamma quería eliminar el patrón Singleton, pero no hubo consenso entre los autores para hacerlo. [9]
Ver también
- Patrón de diseño de software
- Patrones de integración empresarial
- GRASP (diseño orientado a objetos)
- Patrones pedagógicos
Notas
- ^ Magistrado presidente Neil Harrison, Fiscal principal Kent Beck , Abogado defensor Martin Fowler , Tribunal Baliff Brian Foote ; Richard Helm presentó una confesión , mientras que el resto fue juzgado.
Referencias
- ^ Banda de cuatro , Wiki de creación de contenido para proyectos de personas y patrones en el desarrollo de software.
- ^ Richard Helm
- ^ Informe anual de SIGPLAN FY '05
- ^ Graham, Paul (2002). La venganza de los nerds . Consultado el 11 de agosto de 2012 .
- ^ Norvig, Peter (1998). Patrones de diseño en lenguajes dinámicos .
- ^ Hannemann, enero (2002). Implementación de patrones de diseño en Java y AspectJ .
- ^ Acusación
- ↑ The Show Trial of the Gang-of-Four , Brian Foote
- ^ Gamma, Erich; Helm, Richard; Johnson, Ralph (22 de octubre de 2009). "Patrones de diseño 15 años después: una entrevista con Erich Gamma, Richard Helm y Ralph Johnson" . InformIT (entrevista). Entrevistado por Larry O'Brien. Archivado desde el original el 20 de febrero de 2019 . Consultado el 1 de septiembre de 2019 .