Cita:
Originalmente Escrito por manolazo
Hasta que punto es mejor usar este modelo al modelo tradicional para este tipo de apps? Supongo que sera un ejemplo sencillo y que lo ideal seria usarlo para proyectos complejos?
|
En el fondo sigue siendo el modelo de siempre (MVC) metiendo interfaces por medio para que el código que trata con la vista (layouts, textviews, botones...) esté perfectamente aislado (desacoplado) de la lógica de tu aplicación.
O, en otras palabras, que la lógica de tu aplicación esté en una clase independiente y no veas ni una sola referencia a cosas de la vista por ninguna parte. Así, si algún día cambias la vista, tu lógica no cambia. Y si tienes que cambiar la lógica, será más fácil.
Ejemplo muy básico, tienes una app que permite actualizar su contenido online y mezclado con el código que descarga cosas tienes un textView.setText("Actualizando") y un textView.setVisibility(View.VISIBLE).
Lo primero que te dice el sentido común a poco que empieces a cambiar cosas en el código es crear un método en la misma clase que se llame mostrarProgreso() y ahí ya meter el setText y el setVisibility. Al menos ahora el método que descarga cosas no tiene referencias feas a textviews y si algún día quieres cambiar el textview por un progressbar o por una animación súper chula solo tienes que tocar en un sitio.
Sin embargo, la clase sigue teniendo código de lógica o de funcionalidad y código de visualización. La siguiente idea feliz es separarlos. En una clase la lógica y en otra el actualizar la vista. Para que la lógica le pueda decir a la capa de presentación que muestre el mensaje de actualización es necesario que la capa de presentación implemente una interfaz que tenga el método mostrarProgreso()
Y esa es la base del MVP,
añadir una capa de abstracción para que la lógica sólo indique QUÉ hay que mostrar, el CÓMO ya lo decidirá la capa de presentación.
Idem para las acciones del usuario (interacciones), en vez de tratar directamente el evento de un botón con onActualizar(View v) por ejemplo, tu lógica implementa el método actualizar() y otra clase se encarga de llamarlo al recibir el evento del usuario (que puede ser de un botón o igual mañana es un gesto de deslizar, a tu lógica le da igual). En este caso lo que le importa a la lógica es QUÉ acción es (actualizar), no CÓMO se generó (se apretó un botón de nombre tal).
Los modelos, patrones, arquitecturas, etc. no son más que recomendaciones o buenas prácticas. Al final todas van dirigidas a que el código sea más legible, más manejable, menos propenso a errores y más extensible. En definitiva, más intuitivo. Qué aplicar en cada caso ya queda a criterio del desarrollador, desacoplar por desacoplar no tiene sentido (por eso los ejemplos sencillos son desafortunados, da la idea de que es matar moscas a cañonazos).
Con las funciones de refactorización que tiene Android Studio tampoco se tarda mucho en extraer una interfaz y empezar a desacoplar funcionalidad.