Professor Daniel San Martín

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Patrones de Diseño ======

Los patrones de diseño están inspirados en una idea propuesta por Christopher Alexander, un arquitecto —de construcciones civiles y no de software— y profesor de la Universidad de Berkeley. En 1977, Alexander publicó un libro llamado A Pattern Language, en el cual documenta diversos patrones para la construcción de ciudades y edificios. Según Alexander:

<blockquote>
<color black> Cada patrón describe un problema que siempre ocurre en nuestro contexto y una solución para él, de manera que podamos utilizarla un millón de veces.</color>
</blockquote>

En 1995, Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides publicaron un libro adaptando las ideas de Alexander al mundo del desarrollo de software ([[https://dl.acm.org/doi/book/10.5555/186897|enlace]]). En lugar de proponer un catálogo de soluciones para el diseño de ciudades y edificios, propusieron un catálogo con soluciones para resolver problemas recurrentes en el diseño de software. A estas soluciones propuestas en el libro les dieron el nombre de Patrones de Diseño. Ellos definen los patrones de diseño de la siguiente manera:

<blockquote>
<color black> Los patrones de diseño describen objetos y clases que se relacionan para resolver un problema de diseño genérico en un contexto particular. </color>
</blockquote>

Así, para entender los patrones propuestos por la Gang of Four —nombre con el que se conocen los autores y también el libro de patrones de diseño— necesitamos entender: (1) el problema que el patrón pretende resolver; (2) el contexto en el que ocurre este problema; (3) la solución propuesta. En esta wiki, se describen algunos patrones de diseño, siempre con enfoque en estos elementos: contexto, problema y solución. También se muestran varios ejemplos de código fuente.

Además de ofrecer soluciones listas para problemas de diseño, los patrones de diseño se han convertido en un vocabulario ampliamente adoptado por los desarrolladores de software. Así, es común escuchar a desarrolladores decir que usaron una fábrica para resolver un cierto problema, mientras que un segundo problema fue resuelto mediante decoradores. Es decir, simplemente mencionan el nombre del patrón y se sobreentiende que la solución adoptada ya está clara. De manera similar, el vocabulario de patrones de diseño se utiliza mucho en la documentación de sistemas. Por ejemplo, la figura de la página siguiente muestra la documentación de una de las clases de la biblioteca estándar de Java. Podemos ver que el nombre de la clase termina en Factory —que es uno de los patrones de diseño que estudiaremos en breve. En la descripción de la clase, se vuelve a mencionar que es una fábrica. Por lo tanto, los desarrolladores que conocen este patrón de diseño tendrán más facilidad para entender y usar la clase en cuestión.


{{:wiki:doc-pattern.png?400|}}
Documentación de una clase Factory de la API de Java.


Un desarrollador puede beneficiarse del dominio de los patrones de diseño en dos escenarios principales:

  * Cuando esté implementando su propio sistema. En este caso, conocer los patrones de diseño puede ayudarlo a adoptar en su sistema una solución de diseño ya probada y validada.

  * Cuando esté usando un sistema de terceros, como el paquete de Java que implementa la clase DocumentBuilderFactory de la figura. En este caso, el conocimiento de los patrones de diseño puede ayudarlo a entender el comportamiento y la estructura de la clase que necesita usar.

Es importante entender que los patrones de diseño están dirigidos a la creación de diseños de software flexibles y extensibles. Antes de explicar cada uno de los patrones, presentaremos un contexto y un fragmento de código que funciona y produce un resultado. Sin embargo, no da origen a un diseño flexible. Para dejar clara esta inflexibilidad, presentaremos un escenario de extensión del código mostrado, involucrando la implementación de nuevos requisitos. Luego argumentaremos que esta extensión requerirá cierto esfuerzo, que podría minimizarse si usamos un patrón de diseño.

Los cuatro autores del libro de patrones de diseño sostienen que debemos diseñar un sistema pensando en los cambios que inevitablemente ocurrirán —a esto lo llaman //design for change//. Como ellos afirman en la frase, si el //design for change// no es una preocupación, los desarrolladores corren el riesgo de tener que planear pronto un rediseño profundo de sus sistemas. En el libro sobre patrones de diseño, se proponen 23 patrones, divididos en las siguientes tres categorías (los patrones que estudiaremos están linkeados):

  * **Creacionales**: patrones que proponen soluciones flexibles para la creación de objetos. Son: [[pdd_1 | Abstract Factory]], Factory Method, [[pdd_2|Singleton]], [[pdd_3 | Builder]] y Prototype.

  * **Estructurales**: patrones que proponen soluciones flexibles para la composición de clases y objetos. Son: [[pdd_4 | Proxy]], [[pdd_5 |Adapter]], [[pdd_6| Facade]],[[pdd_7 | Decorator]] , Bridge, Composite y Flyweight.

  * **Comportamentales**: patrones que proponen soluciones flexibles para la interacción y división de responsabilidades entre clases y objetos. Son: [[pdd_8|Strategy]], [[pdd_9|Observer]], [[pdd_11|Template Method]], [[pdd_10|Visitor]], Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento y State.
Professor Daniel San Martín

User Tools

Site Tools

Page Tools
