PATRONES ESTRUCTURADOSPATRÓN ADAPTER

Arquitectura de Aplicaciones Integrantes:

Ana Poma

Ismael Armijos

Agenda

• Propósito• Motivación• Diagrama de clases• Aplicabilidad • Estructura • Participantes • Colaboraciones • Consecuencias • Implementación • Ejemplo

Propósito

o Convierte la interfaz de una clase en otra interfaz que es lo que esperan los clientes. Permiten que cooperen clases que de otra forma no podrían por el motivo de que tienen interfaces incompatibles.

• Hay muchas veces en que una clase de un toolkit que ha sido diseñada para reutilizarse, no puede hacerlo porque su interfaz no coincide con la interfaz especificada del dominio que requiere la aplicación.

Motivación

Ejemplo

• En un editor de dibujo que permite que los usuarios dibujen y ubiquen elementos gráficos.

• La abstracción fundamental del editor de dibujo es el objeto gráfico.

• La interfaz de los objetos gráficos esta definida por una clase abstracta llamada Forma.

• El editor define una subclase de Forma para cada tipo de objeto grafico. (FormaLinea, FormaTexto, etc.).

• Un Toolkit comercial de interfaces de usuario podría proporcionar una clase VistaTexto para mostrar y editar texto.

• Para ello se puede definir FormaTexto para que adapte la interfaz VistaTexto (clase existente y no relacionada) a la de Forma. Esto se puede hacer de dos maneras:

1) Heredando la interfaz de Forma y la implementación de VistaTexto, o

2) Componiendo una instancia VistaTexto dentro de una FormaTexto e implementando FormaTexto en términos de la interfaz de VistaTexto.

Diagrama de Clases

• Muchas veces el adaptador es el responsable de la funcionalidad que la clase adaptada no proporciona.

• FormaTexto añade la funcionalidad que VistaTexto no tiene y que es requerida por Forma.

Diagrama de Clases

Aplicabilidad

Se debe usar el patrón Adapter cuando:

• Se requiere usar una clase existente y su interfaz no concuerda con la que necesita.

• Se requiere crear una clase reutilizable que coopere con clases no relacionadas o que no han sido provistas, es decir, clases que no tienen por qué tener interfaces compatibles.

• (Solamente en el caso de un adaptador de objetos) es necesario usar varias subclases existentes, pero no resulta práctico adaptar su interfaz heredando de cada una de ellas. Un adaptador de objetos puede adaptar la interfaz de su clase padre.

• Un adaptador de clase usa la herencia múltiple para adaptar una interfaz a otra:

Estructura

Un adaptador se basa en la composición de objetos:

Participantes

• Objetivo (Forma): define la interfaz especifica del dominio que usa el Cliente.

• Cliente (EditorDeDibujo): colabora con objetos que se ajustan a la interfaz Objetivo.

• Adaptable (VistaTexto): Define una interfaz existente que necesita ser adaptada.

• Adaptador (FormaTexto): adapta la interfaz de Adaptable a la interfaz Objetivo.

Colaboraciones

• Los clientes llaman a operaciones de una instancia de Adaptador. A su vez el Adaptador llama a operaciones de Adaptable, que son las que satisfacen la petición de Cliente.

Consecuencias Adaptador de Clases Adaptador de Objetos

Adapta una clase Adaptable a Objetivo (clase Adaptable únicamente y no a sus subclases).

Permite que un mismo Adaptador funcione con muchos Adaptables (clase Adaptable y sus subclases) y añadir funcionalidad a todos los Adaptables a la vez.

Permite que Adaptador redefina parte del comportamiento de Adaptable, por ser Adaptador una subclase de Adaptable.

Hace que sea más difícil redefinir el comportamiento de Adaptable. Se necesita crear una subclase de Adaptable y hacer que el Adaptador se refiera a la subclase en vez de a la clase Adaptable en sí.

Introduce un solo objeto y no necesita ningún puntero de indirección adicional para obtener el objeto adaptado.

La cantidad de trabajo que hace el Adaptador depende de lo parecida que sea la interfaz de Objetivo a la de Adaptable.

Adaptadores conectables: al hacer la adaptación de interfaces en una clase estamos eliminando la asunción de que otras clases vean la misma interfaz.

Usar adaptadores bidireccionales para proporcionar transparencia, ya que resultan útiles cuando dos clientes distintos necesitan ver un objeto de distinta forma (se crea una subclase heredando de ambos clientes).

Implementación

• Aunque la implementación del patrón Adapter suele ser sencilla, se debe tener en cuenta lo siguiente:

1) Implementación de Adaptadores en C++: Adaptador debería heredar públicamente de Objetivo y privadamente de Adaptable, así Adaptador sería un subtipo de Objetivo pero no de Adaptable.

2) Adaptadores conectables: Existen tres formas de implementar adaptadores conectables.

• Consiste en encontrar una interfaz reducida para Adaptable, es decir, el subconjunto mas pequeño de operaciones que nos permitan hacer la adaptación. La interfaz reducida nos lleva a tres enfoques de implementación:

a) Usar operaciones abstractas

b) Usar objetos delegados

c) Adaptadores parametrizados

Implementación- Adaptadores conectables

Ejemplo

• Pensemos en este problema. En muchos países se utilizan las espigas redondas en los tomacorrientes, y en otros las espigas planitas. En ocasiones tenemos un dispositivo que tiene 3 espigas y el tomacorrientes 2. Sin embargo sabemos que el aparato que deseamos conectar “entiende” la corriente eléctrica, “la acepta”, aunque la interfaz para conectarse a ella sea una distinta a la que posee. ¿Qué hacemos en estos casos? Usamos un adaptador!

• Pues lo mismo sucede con el software. Sucede a menudo que nos encontramos con librerías que pueden sernos de utilidad, pero que existe la necesidad de adaptarnos a ellas.

• En esos casos tenemos dos opciones: modificar todo nuestro código para que se adapte a la librería, o podemos crear un adaptador que traduzca lo nuestro a lo de ellos y lo de ellos a lo nuestro.

Ejemplo• Imaginemos que tenemos un sistema que maneja coches, barcos,

aviones y parecidos. Generalmente los motores que se usan son de gasolina, pero las nuevas tendencias han popularizado los motores eléctricos.

• Tenemos que el proveedor de vehículos eléctricos nos provee sus librerías para el motor eléctrico que es prácticamente igual a nuestras implementaciones pero con otros nombres (prender en vez de encender, “mover más rápido” en vez de acelerar, etc.), y tiene una restricción extra: para poder acelerar o detener el motor, este tiene que estar conectado.

• Surge entonces el problema ¿cómo hacemos para que nuestras librerías puedan hacer uso del motor eléctrico? Podríamos reescribirlas todas, pero el tiempo que eso nos tomaría sería mucho. Además sabemos que existirían problemas que nuestras librerías ya han solucionado.

Ejemplo

• Crear una clase abstracta

Ejemplo• Y tenemos nuestras implementaciones de algunos motores,

por ejemplo el motor económico:

Ejemplo• Y el motor Gastón (que ya no se vende tanto!):

Ejemplo

• Estas clases siempre nos han funcionado bien, y de hecho tienen muchas cosas como servicios, mantenimientos y otros, que usamos gracias a la interfaz motor. Por ejemplo es común que usemos cosas como estás:

Ejemplo

• Ahora la empresa que construye motores eléctricos nos manda su propia implementación que va así:

Ejemplo• Como vemos, este

motor hace lo mismo que el nuestro, pero de manera y con llamadas un poco diferentes. ¿Cómo hacemos para integrar este MotorEléctrico al resto de nuestro sistema? Así es, con un adaptador o adapter!

• El adapter “envuelve” al objeto extraño (por eso le llaman wrapper también, ya que wrapper viene siendo envoltorio). Nuestro adaptador se escribiría así:

Ejemplo• Como ven el adapter se encarga no solo de corregir los

nombres de los métodos, sino también cosas como conectar y desconectar el motor, cosas que a nuestra implementación no le importan. Pero lo más importante es que ahora podemos utilizar esta implementación de Motor en nuestro sistema utilizando la implementación de ellos. Por ejemplo podemos hacer cosas como esta:

Ejemplo

• El patrón adapter aparece en todos lados, aunque muchas veces no se le llama adapter específicamente. Ahora que lo conocemos lo podemos usar en nuevos proyectos, o tal vez puede solucionar los problemas que resolvimos a medias en algún software por ahí.

Salida

Bibliografía

• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (2003). Patrones de Diseño- Elementos de Software Orientado a Objetos Reutilizables. Madrid: PEARSON, EDUCACIÓN, S.A.

• Fernández, L. H. (19 de 11 de 2009). Software Guisho. Recuperado el 13 de 11 de 2011, de Patrón Adaptador – Pattern Adapter – Patrones de diseño: http://software.guisho.com/patron-adaptador-pattern-adapter-patrones-de-diseño.

GRACIAS…

Bibliografía

• http://software.guisho.com/patron-adaptador-pattern-adapter-patrones-de-diseno, “Patron Adaptador – Pattern Adapter – Patrones de diseño”