Patrón de diseño Adapter

El patrón Adapter es mi favorito, es extremadamente sencillo, tiene un caso de uso muy interesante en el frontend: cambios en la api.

Problema

Cambios en dependencias de un módulo (otros componentes, servicios, variable global) afectan su comportamiento.

Ej: getUser respondía:

{ fullname: Joe Doe }

Ahora getUser responde:

{ name: Joe, lastname: Doe, }

El componente que lo requiere usa la información de la siguiente manera:

const Comp = ()=> {
    const user = getUser();
    return <h1>{user.fullname}</h1>
};

Claramente, user.fullname devolverá undefined, y en otros lenguajes daría un error. Entonces, ¿cómo podemos resolver este problema?

Solucion

Evidentemente no podemos simplemente cambiar el componente donde se esté usando getUser() porque probablemente no sea solo uno. Tener que modificar cada componente afectado multiplicaría el trabajo y las probabilidades de terminar con un bug.

Por este motivo lo que debemos hacer es crear un intermediario que transforme la nueva respuesta del servicio respetando el contrato anterior.

const user = getUser();

const response = ${user.name} ${user.lastname};

return response;

En lenguajes orientados a objetos este patrón haría uso de una interface, pero en javascript no es necesaria.

Me parece interesante como este mismo concepto de poner un intermediario entre dos componentes es mal visto en otros contextos, donde se lo llama middle man. Personalmente creo que si la misma lógica está bien o mal según el contexto, entonces está mal la lógica o está mal el contexto.

Los patrones de diseño son soluciones específicas para problemas específicos, considero que el problema con los middle man es que forman parte de el diseño original, tal vez queriendo anticiparse a un futuro problema. YAGNI. En los casos para los que fue diseñado este patrón es simple, elegante y correcto.