Software design patterns on Android Spanish

Software Design Patterns on AndroidPedro Vicente Gómez Sánchez - Mobile Software Engineer, Tuenti Technologies.

@pedro_g_s , @TuentiEng

[email protected]

http://corporate.tuenti.com/es/dev/blog - @TuentiEnghttp://corporate.tuenti.com/es/jobs

Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s

http://corporate.tuenti.com/es/dev/blog


¿Por qué hablar de patrones cuando podríamos estar en el bar?


“Si vuelvo a ver anotaciones para parsing json en una clase del dominio de mi problema, me pego un tiro.”

“Si vuelvo a ver un proyecto en el que no se use inyección de dependencias, me tiro por una ventana.”

“Si vuelvo a ver un proyecto en el que cada clase tenga más de 7 dependencias, me mudo a la India.”

“Si vuelvo a ver una clase de 3000 líneas de código, me paso a programar para iOS.”


Pedro Gómez

● Introducción● Problema a resolver.● Patrones en Android.● Patrón Renderer.● Patrón Repository.● Patrón Command.● Consejos prácticos.


DISCLAIMER


Software Design Patterns on Android - Pedro V. Gómez Sánchez

¿Qué son los patrones?


¿Qué son los patrones?

Un patrón es una posible solución a un problema que se nos plantea de forma que problemas con planteamientos similares puedan ser resueltos de forma similar.


¿Qué define un patrón?

● Nombre● Problema que resuelve● Estructura● Consecuencias


¿Qué tipos existen?

Creación Estructura

Comportamiento


¿Qué tipos existen?

● Creación:○ Abstract Factory.○ Builder.○ Singleton.

● Estructura:○ Adapter.○ Facade.○ Bridge.

● Comportamiento:○ Command.○ State.○ Memento.


Ventajas

● Cada patrón es una solución plausible y definida para problemas concretos.● Facilitan la reutilización de estructuras y evitar duplicación de código.● Facilitan la extensibilidad de código y aceleran el tiempo de desarrollo a largo

plazo.● Desacoplan el código.● Favorecen el cambio.● Reducen los esfuerzos de mantenimiento.● Suelen suponer una mejor asignación de responsabilidades.● Plantean un vocabulario común.● Resuelves problemas ya resueltos por otros desarrolladores.


Inconvenientes

● No es sencillo identificar qué patrón aplicar.● Pueden suponer una sobrecarga de trabajo a corto plazo.● No siempre es trivial aplicar el patrón a un problema concreto.● Pueden afectar al rendimiento.● Pueden provocar la fiebre del patrón o muerte por refactor.● Un patrón mal aplicado puede transformarse en un anti patrón.


Problema a resolver

● Mostrar un conjunto de vídeos en una lista.● Los vídeos serán proporcionados por una API

externa.● Los vídeos podrán ser de varios tipos:

○ Vídeos normales.○ Vídeos populares.○ Vídeos favoritos.○ Vídeos en directo


Patrones en Android

Adapter

Chain of Responsibility

Memento

Model View Controller


Patrones en Android: Adapter

Nombre: Adapter.

Problema: Convertir la interfaz de una clase en otra que el código cliente espera. Permite la colaboración otra clase a pesar de tener una interface incompatible.

Nuestro problema: Permitir que Android pinte una serie de vistas sobre un ListView sin conocer la implementación que le daremos en el futuro.


Patrones en Android: Adapter


Patrones en Android: MementoNombre: Memento.

Problema: Capturar y externalizar el estado de un objeto interno, sin violar la encapsulación, de modo que el objeto pueda ser restaurado a este estado más tarde.

Nuestro problema: Guardar el estado de la actividad para recuperarlo ante un reinicio del ciclo de vida de la misma.


Patrones en Android: Memento


Patrones en Android: Chain of ResponsibilityNombre: Chain of Responsibility.

Problema: Evita acoplar el emisor de una petición a su receptor dando a más de un objeto la posibilidad de responder a una petición. Para ello, se encadenan los receptores y pasa la petición a través de la cadena hasta que es procesada por algún objeto.

Nuestro problema: Notificar eventos a lo largo de nuestra aplicación hasta que uno de los receptores o varios decida procesarlo.


Patrones en Android: Chain of Responsibility


Patrones en Android: Model View Controller

Nombre: Model View Controller.

Problema: Desacoplar la implementación de las vistas y la de nuestro modelo.

Nuestro problema: Crear una aplicación de forma que la implementación de nuestras vistas y el modelo que implementa la lógica de negocio no esten acopladas.


UN ACTIVITY NO ES UN CONTROLADOR!!!


Problema a resolverPintado de la lista Procedencia de los

datosCasos de uso


Renderer

Software Design Patterns on Android - Pedro V. Gómez Sánchez - [email protected]


RendererNombre: Renderer.

Problema: Desacoplar el proceso de pintado de elementos heterogéneos en una lista.

Nuestro problema: Tenemos vídeos de diferentes tipos que tienen que pintarse de forma diferente. Vídeos normales, vídeos populares, vídeos favoritos y vídeos en directo.


RendererEstructura: Este patrón es una combinación de tres patrones.

● Builder: Separa la construcción de un objeto complejo de su representación, así que el mismo proceso de construcción pueda crear diferentes representaciones.

● Delegate: Patrón aplicado cuando una clase delega su implementación en otra clase que actúa como helper.

● Template Method: Define el esqueleto de un algoritmo en una operación, difiriendo algunos pasos en las subclases.


RendererBuilder: Crear o reciclar una vista en el método getView de un adapter es un proceso de creación complicado que podemos implementar utilizando el patrón builder.


Builder


Renderer

Template Method: Aplicando este patrón podemos crear una estructura general para el algoritmo de pintado de los vídeos en la lista de forma que los subtipos especialicen el algoritmo y cambien o añadan el contenido que deseen duplicando la menor cantidad de código posible.


Template method


RendererDelegate: La implementación clásica de el método getView se basa crear, reciclar y setear el contenido de la vista para pintarla apropiadamente, con el patrón delegate podremos delegar la implementación del pintado de la vista sobre los objetos de tipo Renderer.

Renderer


RendererDelegate: Con este cambio de implementación puede observarse cómo la implementación que vimos en transparencias anteriores se ve reducida a la siguiente.


Renderer


Merece la pena?


Resultado?


Renderer


Un adaptador para adaptarlos a todos?


https://github.com/pedrovgs/Renderers


RepositoryNombre: Repository.

Problema: Abstraer el origen de datos de un sistema con posibles fuentes de información.

Nuestro problema: Abstraer la procedencia de los datos, si proceden de un sistema de almacenamiento basado en memoria, persistencia o si los datos proceden de la api.


Repository

Diferentes implementaciones de la interface repositorio pueden ofrecer diferentes prestaciones abstrayendo por completo al resto del sistema.


¿Por qué?


¿Qué importa si la aplicación tiene una base de datos o un fichero o una API

externa?


Repository


CommandNombre: Command.

Problema: Encapsular un mensaje como un objeto, permitiendo parametrizar los clientes con diferentes solicitudes, añadir a una cola las solicitudes y soportar undo redo.

Nuestro problema: Modelar los casos de uso de la aplicación de forma que abstraigamos el proceso de ejecución de los mismos.


Command Casos de uso


Command


Consejos prácticos● Un modelo por dominio.● Evitar la duplicidad de código.● Refactorizar día a día.● Cumplir el principio de responsabilidad única.● Tomar las decisiones importantes cuando sea necesario.● Pensar en el framework como un mecanismo de paso de

información.● Desarrollar desde el caso de uso.● Crear código testable.● Escribir código para los compañeros no para la máquina


¿Preguntas?

http://corporate.tuenti.com/es/dev/blog - @TuentiEnghttp://corporate.tuenti.com/es/jobs




Software design patterns on Android Spanish

Documents

Transcript of Software design patterns on Android Spanish