Patrones Diseño en Dllo SW Arquitectura SW 2 1

Arquitectura de SoftwareIngeniería de SistemasITMUnidad 2. Los patrones de diseño en el desarrollo de SoftwareUnidad 2.1 Patrones orientados a la creación

Arquitectura de Software

Los patrones de Diseño en el Desarrollo de Software

El inicio de los patrones de diseño se dio en 1979, cuando el arquitecto Christopher Alexander publicó el libro “The Timeless Way of Building”, que se constituyó en un gran

aporte para la arquitectura.

Antecedentes e historia



En este libro, el autor, proponía el aprendizaje y uso de una serie de patrones para la construcción de edificios de una mayor calidad.




El autor asegura que “Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizarla un millón de veces más

sin tener que pensarla otra vez”.




Tras el éxito de los patrones en la arquitectura, en 1987, Ward Cunningham y Kent Beck se basaron en varias ideas de Alexander para desarrollar cinco patrones de intracción hombre-computador (HCI) y publicaron un

artículo “Using Pattern Languages for OO Programs”.




Sin embargo, no fue hasta principios de los 90’s cuando los patrones de diseño tuvieron un gran éxito en el mundo de la informática tras la publicación del libro “Design Patterns” escrito por el grupo denominado GoF

(Gang of Four), que en español significa “La pandilla de los cuatro”.




En esta publicación el grupo GoF recogía 23 patrones de diseño comunes para el desarrollo de Software.




Los 23 patrones, mencionados anteriormente, están organizados por dos criterios: Propósito (de creación, estructurales y de

comportamiento). Ámbito (clase y objeto).

Catalogo de patrones de diseño



Aspectos de diseño que los patrones de diseño permiten modificar

Propósito Patrones de diseño

Aspectos que pueden variar

De creación

Abstract Factory La familia de los objetos producidos

Builder Cómo se crea un objeto compuesto

Factory Method La subclase del objeto que es instanciado

Prototype La clase del objeto que es instanciado

Singleton La única instancia de una clase






Estructurales

Adapter La interfaz de un objeto

Bridge La implementación de un objeto

Composite La estructura y composición de un objeto

Decorator Las responsabilidades de un objeto sin usar la herencia

Facade La interfaz de un subsistema

Flyweight El coste de almacenamiento de los objetos

Proxy Cómo se accede a un objeto; su ubicación






De comportamie

nto

Chain of Responsibility

El objeto que puede satisfacer una petición

Command Cuándo y cómo se satisface una petición

Interpreter La gramática e interpretación de un lenguaje

Iterator Cómo se recorren los elementos de un agregado

Mediator Qué objetos interactúan entre sí, y cómo

Memento Qué información privada se almacena fuera de un objeto, y cuándo

Observer El número de objetos que dependen de otro; cómo se mantiene actualizado el objeto dependiente






De comportamie

nto

State El estado de un objeto

Strategy Un algoritmo

Template Method Los pasos de un algoritmo

Visitor Las operaciones que pueden aplicarse a objetos sin cambiar sus clases

Patrones orientados a la creación

Los patrones de creación están asociados al proceso de creación de los objetos, entre objetos se delegan los procesos de creación.



Nombre: Fabricación AbstractaFunción: Proporciona una interfaz para crear familias

de objetos relacionados o dependientes sin especificar las clases concretas de las que son instancia.

Si deseamos que nuestro software funcione sobre distintos recursos debemos abstraer las librerías utilizadas proporcionando una interfaz común.


Abstract Factory


Consideremos un juego de herramientas para construir interfaces de usuario que soporte múltiples estándares look-and-feel.

◦ Diferentes look-and-feel definen diferentes aspectos (colores, figuras, tipos de letra, etc.) y comportamientos (botones, menús, barras de scroll, ventanas, etc.)

◦ Por ejemplo: Motif, Presentation Manager, Open Window, etc.


Abstract Factory: Motivación


Una aplicación que use estas características no debería codificar explícitamente la creación de objetos específicos del look-and-feel concreto, pues ello complicaría la modificación posterior del mismo.

Tampoco es razonable contemplar las distintas posibilidades de look-and-feel mediante sentencias condicionales que se repiten cada vez que se crea un panel o ventana; sería difícil extender la aplicación a nuevos look-and-feel.


Abstract Factory: Motivación



Abstract Factory: Una solución “ingenua”



Abstract Factory: Una solución “menos ingenua”



Abstract Factory: Solución



Abstract Factory: Aplicación



Abstract Factory: Una solución “menos ingenua”



El patrón Fabrica Abstracta - Abstract Factory -



Abstract Factory: Algunas consideraciones


Es un patrón de creación de objetos

Intención: Asegura que una clase tiene una única instancia y proporciona un punto de acceso global a dicha instancia.Motivación: Hay veces que es importante asegurar que

una clase tenga una sola instancia, por ejemplo:


Singleton: Singular

• Un gestor de ventanas • Una única cola de impresión

• Un único sistema de ficheros

• Un único fichero de log, o un único repositorio


Motivación:

¿Cómo asegurarlo? Una variable global hace el objeto accesible, pero se puede instanciar varias veces.

Responsabilidad de la clase misma: actuar sobre el mensaje de creación de instancias.


Singleton: Singular


Solución:

Para asegurar que se crea una sola instancia El constructor de la clase no debe ser público.

El almacenamiento de la instancia Se hará en una variable de clase (estática).

El acceso a dicha variable Se hará a través de un método de clase (estático), que

devolverá una referencia a la instancia. La creación de la instancia

Se hará la primera vez que se invoque este método.


Singleton: Singular


El Patrón Singular:


Singleton: Singular


Singleton: Implementa la instancia única.

Cliente: Define una operación “instancia” para que el cliente pueda acceder por instancia única.


Singleton: Singular


Aplicación:

Se recomienda el uso del patrón Singleton cuando: El sistema exige exactamente una instancia de

una clase, la cual debe ser accesible para los clientes desde un punto de acceso bien definido.

La única instancia debe ser extendida a subclases y los clientes deben ser capaces de usarla sin modificar su código.


Singleton: Singular


Consecuencias:

Acceso controlado a la única instancia.Espacio de nombre reducido. Mejora sobre el

uso de variables globales.Permite el refinamiento de operaciones y la

representación. Se puede subclasificar de la clase Singleton y configurar la aplicación con una instancia de esta clase.


Singleton: Singular


Consecuencias:

Fácil modificación para permitir un número variable de instancias.

Más flexible que las operaciones de clase.


Singleton: Singular


Colaboraciones:

Un patrón Singleton es frecuentemente relacionado y empleado en la implementación del patrón Abstract Factory –Fábrica Abstracta-, sobre todo cuando se trata de una fábrica concreta.


Singleton: Singular

Documents

Patrones Diseño en Dllo SW Arquitectura SW 2 1