Diseño

Patrones Estructurales (IV): Patrón Bridge


Objetivo:

“Desacoplar una abstracción de su implementación de modo que los dos puedan ser modificados de forma independiente.”

Design Patterns: Elements of Reusable Object-Oriented Software

El patrón Bridge o Puente es normalmente uno de los patrones que más cuesta entender, especialmente si nos ceñimos únicamente a su descripción. La idea tras este patrón, sin embargo, es sencilla: dado que cualquier cambio que se realice sobre una abstracción afectará a todas las clases que la implementan, Bridge propone añadir un nuevo nivel de abstracción entre ambos elementos que permitan que puedan desarrollarse cada uno por su lado.

Si le echamos un ojo al diagrama, es posible que de base no nos aclare demasiado. Nos centraremos en el elemento central: una clase abstracta Abstracción que contiene una referencia a una interfaz Implementor y un método operacion() que no hace más que invocar el método operacionOriginal() de dicha interfaz. Lo que hace esta clase Abstracción es, por tanto, encapsular a la interfaz Implementor exponiendo sus métodos.

(más…)

Anuncios

Patrones Estructurales (III): Patrón Decorator


Objetivo:

“Añadir responsabilidades a un objeto de forma dinámica. Los decoradores proporcionan una alternativa flexible a la herencia para extender funcionalidad.”

Design Patterns: Elements of Reusable Object-Oriented Software

El siguiente de los patrones estructurales que veremos sera el patrón Decorator o decorador. Su filosofía consiste en añadir responsabilidades de forma dinámica con el principal objetivo de evitar la conocida como “explosión de clases”, es decir, la generación de un número elevado de subclases a partir de una superclase común.

Como podemos observar en el gráfico superior, la clase Decorator hereda de la misma clase que el componente que se quiere decorar. Así, cada decorador es capaz de encapsular una instancia de cualquier otro objeto que herede del componente común, bien un componente concreto u otro decorador. Este comportamiento recuerda al que vimos previamente en el patrón Adapter, con la diferencia de que la clase Decorator, a diferencia de la clase Adapter, no transforma una interfaz, sino que añade cierta funcionalidad.

(más…)

Patrones Estructurales (II): Patrón Facade


Objetivo:

“Proporcionar una interfaz unificada a otro conjunto de interfaces de un subsistema. Façade define una interfaz de más alto nivel que hace que el subsistema más fácil de usar.”

Design Patterns: Elements of Reusable Object-Oriented Software

Cuando vimos el patrón Adapter dijimos que el patrón Facade (fachada) estaba muy relacionado con él. Si bien ambos patrones se basan en el mismo principio (encapsular la interfaz de otros elementos), es el motivo y el uso que se le va a dar lo que las diferencia:

  • El patrón Adapterconvierte una interfaz en otra, haciendo que la clase cliente pueda utilizar los métodos de una clase para cuya interfaz no estaba originalmente preparado.
  • El patrón Facade, sin embargo, no realiza ninguna transformación, sino que se limita a simplificar y centralizar un conjunto de invocaciones en un único punto, a la vez que desacopla al cliente del subsistema (siendo la clase Facade la que quedaría acoplada). Es importante tener en cuenta que el patrón Facade no realiza operaciones de transformación, ya que las clases del subsistema, pese a ser envueltas con este elemento, pueden seguir siendo accesibles de forma normal en caso de que fuese necesario, al contrario de lo que ocurre con el patrón Adapter. Un Facade es una forma de simplificar las cosas: es decisión del diseñador si las clases del subsistema son accedidas de forma directa o a través de la fachada.

Resumiendo, Adapter transforma mientras que Facade simplifica y desacopla.

(más…)

Patrones Estructurales (I): Patrón Adapter (Wrapper)


Objetivo:

Convertir la interfaz de una clase en otra interfaz que el cliente espera. Adapter consigue que trabajen juntas clases que de otro modo no podrían.

Design Patterns: Elements of Reusable Object-Oriented Software

El patrón Adapter nos abre el camino hacia el segundo grupo de patrones propuestos por el Gang of Four: los patrones estructurales. Si bien los patrones de creación definían la forma en la que los objetos son instanciados, los patrones estructurales se basan en la forma en la que un conjunto de clases se relacionan entre sí para proporcionar una funcionalidad compleja, proporcionando una estructura para conseguir lograr ese objetivo.

La filosofía de Adapter, al igual que vimos con Prototype, es tan simple como autoexplicativa: establecer una capa intermedia que permita comunicarse a dos clases que de otro modo no podrían hacerlo, realizando una adaptación de la interfaz de la clase que proporciona el servicio a la que la solicita.

(más…)

Patrones de creación (IV): Patrón Singleton


Objetivo:

“Asegurarse de que una clase tiene una única instancia, proporcionando acceso global a ella.”

Design Patterns: Elements of Reusable Object-Oriented Software

Hay clases que deben instanciarse una única vez. El acceso a un sistema de archivos, a la cola de impresión o al gestor de ventanas del sistema operativo debería realizarse por un único objeto, siendo labor de la propia clase el controlar que la instancia sea única. Por norma general, esta clase será accesible de forma global, y el proceso de instanciado no suele requerir parámetros.

Como podemos observar en el diagrama, nuestra clase Singleton constará al menos con dos métodos:

  • Un método Instance() de carácter estático (método de clase) que se encargará de instanciar la clase.
  • Un constructor privado que evitará que se creen nuevos objetos mediante new(), haciendo que el método Instance() sea el único que puede generar la instancia.

(más…)

Patrones de creación (III): Patrón Prototype


Objetivo:

“Especificar el tipo de objetos que se crearán utilizando una instancia prototipada y crear nuevos objetos realizando copias de ese prototipo.”

Design Patterns: Elements of Reusable Object-Oriented Software

El concepto de este patrón es simple: en lugar de crear un objeto, se clona, es decir, se realiza una copia exacta de otro objeto dado, denominado prototipo.

Entran en juego tres elementos:

  • Cliente: clase que solicita al prototipo que se clone.
  • IPrototipo: interfaz o clase abstracta que define la operación de clonado.
  • PrototipoConcreto: implementa IPrototipo y su método Clone() para proceder al clonado del objeto.

El proceso de clonado comienza instanciando una clase de forma habitual. Una vez que disponemos de una instancia funcional, el resto de instancias se generarán creando copias de la primera.

La forma de aplicar este patrón es simple:

  • Se define una interfaz que expondrá el método utilizado para realizar el clonado del objeto.
  • Las clases que realicen el clonado utilizarán este método para esta operación.

(más…)

Patrones de creación (II): Patrón Builder (Constructor)


Objetivo:

“Separar la construcción de un objeto complejo de su representación, de modo que el mismo proceso de construcción pueda crear representaciones diferentes.”

Design Patterns: Elements of Reusable Object-Oriented Software

Patrón Builder

Hablando en plata, el patrón Builder es un patrón creacional cuyo objetivo es instanciar objetos complejos que generalmente están compuestos por varios elementos y que admiten diversas configuraciones. Cuando hablamos de “construcción” nos referimos al proceso, mientras que cuando hablamos de “representación” nos estaremos refiriendo a los datos que componen el objeto. Se encargará, por tanto, de encapsular todo el proceso de generación de modo que únicamente necesite los detalles necesarios para “personalizar” el objeto, devolviendo como resultado una instancia del objeto complejo que deseamos construir. Es un patrón fuertemente ligado a otro, el patrón estructural Composite, del que hablaremos en posteriores artículos.

(más…)