Patrón de Diseño Adaptador para Transformar Datos en Clases Java
Resumen
¿Qué es un patrón de diseño y cómo funciona un adaptador?
La programación y el desarrollo de software están llenos de patrones de diseño que nos ayudan a crear mejores aplicaciones. Uno de estos patrones es el adaptador, el cual funciona como un mediador entre dos clases que, por sí solas, no se entienden. A menudo, esto se aplica cuando una clase o sistema recibe datos de una fuente externa, como podría ser una API, y no todos esos datos son necesarios para la aplicación en cuestión. Aquí es donde el adaptador juega un papel crucial: traduce y simplifica esos datos para que la clase receptora pueda manejarlos de manera más eficiente.
¿Por qué usar un adaptador?
La necesidad de un adaptador surge cuando dos entidades no pueden comunicarse directamente debido a sus incompatibilidades. El adaptador sirve como un traductor entre estas entidades, permitiendo que la comunicación fluya de manera eficiente sin requerir cambios significativos en ambas partes.
Ventajas del uso del adaptador:
Simplifica la estructura de la aplicación al separar la lógica de negocio del manejo de datos.
Facilita el mantenimiento, ya que las modificaciones se concentran en un solo lugar.
Proporciona flexibilidad para gestionar cambios en el proveedor de datos externo sin afectar a la vista o la lógica de la aplicación.
¿Cómo implementar un adaptador en Kotlin?
Veamos un ejemplo práctico de cómo implementar un adaptador en Kotlin. Empezamos por crear una clase de datos que simula una respuesta de una API, luego creamos un adaptador que customize esta información para una vista de usuarios.
En el ejemplo anterior, la clase GitUserResponse representa la estructura de datos que recibimos del sistema externo. Ahora creamos un adaptador que procesa esta información.
La clase UserAdapter traduce GitUserResponse en un UserViewModel, que es más adecuado para la vista da la aplicación.
UserViewModel incluye solo los datos necesarios: el nombre de usuario y la URL de la foto del usuario.
¿Cómo manejar cambios en las respuestas?
Un caso común es cuando las respuestas de una API cambian y comienzan a devolver datos bajo diferentes nombres. En lugar de cambiar todas las vistas directamente, solo se debe ajustar el adaptador, lo que minimiza el impacto.
classUserAdapter(privateval gitUserResponse: GitUserResponse){funtoViewModel(): UserViewModel {returnUserViewModel( userName = gitUserResponse.doc,// Cambio en la fuente de datos userPhoto = gitUserResponse.userPhotoUrl
)}}
Con este enfoque:
Adaptabilidad: Solo el adaptador requiere ajustes frente a cambios en el proveedor de datos.
Consistencia: La vista y el presentador no se ven afectados, dando estabilidad al sistema.
Escalabilidad: Se puede utilizar el mismo patrón para otros tipos de datos o vistas, facilitando la extensión del proyecto.
El adaptador, por lo tanto, se convierte en una herramienta fundamental en el desarrollo de aplicaciones modernas, facilitando la integración y eficiencia de las soluciones. Continúa explorando y experimentando con patrones de diseño para enriquecer tus proyectos. ¡El aprendizaje nunca se detiene!
Adapter es el mediador cuando dos clases no se entienden y su única responsabilidad es adaptar una clase cuando la otra no la entienda
Gracias por este aporte
Al tener varias vistas y modificarse el Response, al usar el Adapter nos ahorra cambiar la capa de vista y la de presentador, adapta las vistas al Response ahorrando cambiar cada una de las vistas que consumen los datos de ese Response que cambio.
buen aporte
¿Que diferencia hay entre un adapter y un mapper en una clean architecture?
Es igual, solo que tiene diferente nombre. Por ejemplo dice aquí
"The mapper usually serves as an adapter between your domain entities and data transfer entities."
Vengo del curso de Kotlin para Android y tu explicación es mucho mas completa que en el curso antes mencionado.
Saludos
¿Por qué el viewModel se maneja cómo data class? Entiendo que este mismo nos facilita la comunicación entre la capa de datos y la de Presentación, puede tener lógica .
Se usa como data class por que lo tomo como un ejemplo de una capa, para que se enfoquen en el patrón y no en la distribución de capas. Pero realmente debería ser una Class que herede de ViewModel
Este tipo de ejemplo aplica también si obtenemos datos de una base de datos y de un api rest, las propiedades no son las mismas de las que se muestran en la capa de la vista.