VIPERDESIGN PATTERN

Padrão de projeto arquitetural▪ Arquitetura "limpa"

▪ Divisão em módulos

▪ Princípio da responsabilidade única

class Car {func accelerate() {}func brake() {}func turnLeft() {}func turnRight() {}func addFuel() {}func changeOil() {}func rotateTires() {}

}

class Car {func accelerate() {}func brake() {}func turnLeft() {}func turnRight() {}func addFuel() {}func changeOil() {}func rotateTires() {}func adjustDriverSeat()

{}func turnOnAC() {}func playCD() {}

}

Violação do princípio

▪Um carro pode ser dirigido

▪Um carro deve receber manutenção

▪Um carro deve prover conforto

class DrivableCar {func accelerate() {}func brake() {}func turnLeft() {}func turnRight() {}

}

class MaintainableCar {func addFuel() {}func changeOil() {}func rotateTires() {}

}

class ComfortableCar {func adjustDriverSeat()

{}func turnOnAC() {}func playCD() {}

}

protocol Drivable {func accelerate() {}func brake() {}func turnLeft() {}func turnRight() {}

}

protocol Maintainable {func addFuel() {}func changeOil() {}func rotateTires() {}

}

protocol Comfortable {func adjustDriverSeat()

{}func turnOnAC() {}func playCD() {}

}

class Car: Drivable, Maintainable, Comfortable {func accelerate() {}func brake() {}func turnLeft() {}func turnRight() {}

func addFuel() {}func changeOil() {}func rotateTires() {}

func adjustDriverSeat() {}func turnOnAC() {}func playCD() {}

}

class Car: Drivable, Maintainable, Comfortable {let drivable = DrivableCar()

let maintenable = MaintainableCar()let confortable = ComfortableCar()

func accelerate() { drivable.accelerate() }func brake() { drivable.brake() }func turnLeft() { drivable.turnLeft() }func turnRight() { drivable.turnRight() }

func addFuel() { maintenable.addFuel() }func changeOil() { maintenable.changeOil() }func rotateTires() { maintenable.rotateTires() }

func adjustDriverSeat() { confortable.adjustDriverSeat() }func turnOnAC() { confortable.turnOnAC() }func playCD() { confortable.playCD() }

}

View

View▪ Mostra informações para o usuário

▪ Recebe comandos vindos do Presenter sobre o que exibir

▪Detecta interações e notificar o Presenter

Presenter

Presenter▪ Diz para a View o que ela deve executar

▪ Responsável por cuidar do estado da View

▪Recebe callbacks do Interactor

Interactor

Interactor▪ Implementação dos casos de uso

▪Integração com API, DB...

▪ Envia os dados recebidos externamente para o Presenter realizar o tratamento necessário antes de atualizar a View

▪O trabalho realizado pelo Interactor deve ser independente de qualquer UI

Entity

Entity▪ São modelos manipulados pelo

Interactor

▪ Entity != Data Access Layer

▪Na maioria das vezes os modelos acabam sendo PONSOs

Router

Router▪ Responsável pela transação entre

diferentes módulos

▪ Responsável pela inicialização do próximo módulo a ser chamado.

▪Responsável pela customização de animações entre telas

Conclusão▪ Maior facilidade em encontrar e resolver bugs

▪ Código mais "limpo" e compacto

▪ Gera uma maior reusabilidade do código

▪ Maior facilidade em adicionar/modificar features▪Fácil e rápido de escrever testes automatizados

confiáveis

Dúvidas?

https://br.linkedin.com/in/pedrohperalta

pedrohperalta

@pedrohperalta

Referênciashttp://clean-swift.com/single-responsibility-principle-for-class/

https://www.objc.io/issues/13-architecture/viper/

https://www.ckl.io/blog/ios-project-architecture-using-viper/