El patrón Adapter permite que las clases con interfaces incompatibles trabajen juntas mediante la conversión de la interfaz de una clase en otra interfaz que los clientes esperan. Se utiliza cuando se necesita usar una clase existente cuya interfaz no coincide con la requerida o cuando se requiere crear una clase reutilizable que coopere con clases no relacionadas. El adaptador envuelve la clase existente y adapta su interfaz para que coincida con la interfaz requerida por los clientes.

1. PATRONES
ESTRUCTURADOS
PATRÓN ADAPTER
Integrantes:
Arquitectura de Aplicaciones Ana Poma
Ismael Armijos

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

3. 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.

4. Motivación
• 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.

5. 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.

6. Diagrama de Clases
• 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.

7. 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.

8. 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.

9. Estructura
• Un adaptador de
clase usa la
herencia múltiple
para adaptar una
interfaz a otra:
 Un adaptador se
basa en la
composición de
objetos:

10. 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.

11. 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.

12. Consecuencias
Adaptador de Clases Adaptador de Objetos
Adapta una clase Adaptable a Objetivo Permite que un mismo Adaptador funcione
(clase Adaptable únicamente y no a sus con muchos Adaptables (clase Adaptable y
subclases). sus subclases) y añadir funcionalidad a
todos los Adaptables a la vez.
Permite que Adaptador redefina parte del Hace que sea más difícil redefinir el
comportamiento de Adaptable, por ser comportamiento de Adaptable. Se necesita
Adaptador una subclase de Adaptable. 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).

13. 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.
1) Adaptadores conectables: Existen tres formas de
implementar adaptadores conectables.

14. Implementación- 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

15. 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.

16. 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.

17. Ejemplo
• Crear una clase abstracta

18. Ejemplo
• Y tenemos nuestras implementaciones de algunos
motores, por ejemplo el motor económico:

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

20. 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:

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

22. 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í:

23. 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:

24. 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í.

25. Salida

26. 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.

27. GRACIAS…

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