Software design patterns on Android Spanish

Software Design Patterns on Android
Pedro Vicente Gómez Sánchez - Mobile Software Engineer, Tuenti Technologies.
@pedro_g_s , @TuentiEng
pgomez@tuenti.com

http://corporate.tuenti.com/es/dev/blog - @TuentiEng
http://corporate.tuenti.com/es/jobs
Software Design Patterns on Android - Pedro V. Gómez Sánchez - @pedro_g_s

¿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: Memento
Nombre: 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 Responsibility
Nombre: 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 resolver
Pintado de la lista Procedencia de los
datos
Casos de uso

Renderer
Software Design Patterns on Android - Pedro V. Gómez Sánchez - pgomez@tuenti.com

Renderer
Nombre: 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.

Renderer
Estructura: 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.

Renderer
Builder: 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

Renderer
Delegate: 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

Renderer
Delegate: 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?

Un adaptador para adaptarlos a todos?

https://github.com/pedrovgs/Renderers

Repository
Nombre: 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

Command
Nombre: 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?

Software design patterns on Android Spanish

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Software design patterns on Android Spanish

Semelhante a Software design patterns on Android Spanish (20)

Software design patterns on Android Spanish