Utilizando
Sealed Classes
para controle de fluxos
alexrios.github.io
alex.rios@protonmail.com
@alextrending
Alex Rios
Quem sou eu?
Gosto de implementar sistemas embarcados e fazer integrações não usuais.
Me interesso por testabilidade, qualidade e explicitação do código e arquitetura baseadas em Event Sourcing.
Por onde passei até agora
Agenda
-
O problema com as exceções
-
Sealed Classes
-
Benefícios
-
Seja Exaustivo
-
Variações
-
Adeus exceções?
O problema com as exceções
O que é uma exceção?
desvio de uma regra ou de um padrão convencionalmente aceito
O que é um tratamento de exceção?
O mecanismo da linguagem que é responsável por lidar com as condições que alteram o fluxo de execução.
A anatomia do tratamento de exceções
clausula de marcação
try, ou outra palavra reservada para inicio de um bloco de código.
bloco de tratamento
catch - except - rescue
Bloco independente da ocorrência da exceção
finally - ensure
O que tem de errado com esse código?
Esse código é passível de erros. Você sabe como lidar com as falhas dessa chamada?
Kotlin não te obriga a tratar as exceções pois não existem exceções checadas.
Mais sobre checked exceptions
Rod Waldhoff
Bruce Eckel
Anders Hejlsberg
checked exceptions
No inicio você se sente mais seguro com elas, mas depois elas não deixam você nadar mais rápido.
Lendo o código descobrimos que temos que tratar a UserProfileClientException
Agora já sabemos que esse erro receberá o tratamento adequado
-
Ininteligível (try-catch hell)
-
Não é fácil identificar qual método lançou a exceção
-
Tratamos todos os erros possíveis?
-
Fluxo de execução confuso
-
Muitos round-trips no código para descobrir o que esta acontecendo
E se tivéssemos um jeito de modelar o nosso resultado da chamada em um objeto que mapeasse o sucesso e falha?
Sealed Classes!
Sealed classes são usadas para representar hierarquias de classes restritas.
Ambos são conjuntos de valores restritos, mas cada constante enum existe apenas como uma única instância, enquanto uma subclasse de uma classe selada pode ter várias instâncias que podem conter estado.
Sealed Classes vs. Enums
Uma sealed class dentro de um when força todos os casos a serem tratados.
Em um exemplo mais complexo
Benefícios
Menos erros. Código agora é type-safe e podemos contar com o Intellisense da sua IDE favorita.
O fluxo dos dados agora não é ambíguo, garantido pelo compilador.
Legibilidade. Com uma boa nomenclatura e o uso do when é muito simples acompanhar o código.
Rastreabilidade & Previsibilidade. A execução não tem saltos inesperados. O fluxo pode ser lido de cima para baixo.
Alguns pontos sobre modelagem baseada em resultado
Ter o objeto Error reflete melhor a realidade e eleva seu tratamento a first class citizen da logica de negocio.
O objeto pode ser passado pelas chamadas
(ex. Pode ser colocado em uma fila).
Melhor suporte ao idioma funcional. requestUserProfile() sempre retorna um valor.
Nada alem disso pode acontecer (como lançar uma exceção).
Isso torna mais fácil o uso de lambdas e a collections API.
Processamento em Batch e paralelização de multiplos requests fica mais fácil de implementar (comparado com a versão com métodos lançando exceções).
Result Class Genérica
Seja Exaustivo
Para tirar máximo proveito das sealed classes, when deve ser usado como uma expressão
Forçando a exaustão
Variações
Alguns casos sem estado
Enum quando todos os casos forem sem estado
Utilizando propriedades nos objetos de resultado
Imagine a implementação da função
Adeus exceções?
Não!
Ainda precisamos de exceções.
Sugestão
Use result objects para chamadas externas (chamadas a uma API).
Ou algo mais sofisticado que apenas logar.
Sugestão
Use exceções quando vc não tem nenhuma ação a tomar.
ex: log, database fora do ar.
Use o que funciona para você e para sua equipe
Não é uma formula mágica de controlar estado e fluxos. É apenas mais uma opção.
alexrios.github.io
alex.rios@protonmail.com
@alextrending