Use case of refactoring to solid principles

1. S.O.L.I.D

2. O que é S.O.L.I.D?
• Cinco princípios criados por Robert C. Martin
(Uncle Bob)
• São guidelines para construir código legível e
extensível.

3. S.O.L.I.D.
• S - Single responsibility principe
• O - Open-closed principe
• L - Liskov substitution principe
• I - Interface segregation principe
• D - Dependency inversion principe

4. Single responsibility principe
• Uma classe deve ter apenas uma única
responsabilidade.
• Responsabilidade = A classe só deve mudar
por apenas um motivo

5. Open-closed principe
• Uma classe deve ser aberta para extensão e
fechada para modificação
• Devemos evitar ao máximo modificar código.
Devemos criar classes que possam ter seu
comportamento modificado sem necessidade
de se alterar o código.

6. Liskov substitution principe
• Subclasses devem conseguir ser usadas em
qualquer local das classes pais.
• Subclasses não podem restringir o
funcionamento de suas superclasses

7. Interface segregation
principe
• Nenhuma classe deve implementar métodos
que ela não precisa.
• Interfaces devem conter o mínimo necessários

8. Dependency inversion
principe
• Modulos de alto nível não devem depender de
modulos de baixo nível. Ambos devem
depender de abstração
• Abstração não deve depender de
implementação. Implementação deve depender
de abstração.

9. Caso de Uso
• Cenário:
• Já existia um código com as seguintes especificações:
• Formatava os emails
• Enviava emails
• Era tentado realizar o envio no máximo três vezes
por email
• Cada tentativa era realizado o Log de erro ou
sucesso.

10. Pseudo código

11. S.O.L.I.D
• Esse código funciona?
• Esse código tem algum problema?
• É fácil de adicionar novas funcionalidades?
• S.O.L.I.D. é sobre código fácil de dar
manutenção e de se alterar

12. Nova especificação
• Iria existir agora dois tipos de envio:
• A lógica de envio seria diferente porque seria
usado um novo serviço para um grupo de
clientes
• A lógica de Log seria diferente por questões
técnicas desse novo serviço
• A formatação seria outra para esses clientes

13. Nova especificação
• O modo antigo ainda vai continuar existindo
• Não se sabe se no futuro haverá outras
mudanças desse tipo.

14. Single responsibility
• Enviar email
• Gerar log
• Realizar tentativas
• Formatar o email
• Escolher o tipo de método de envio

15. Open-closed
• O único ponto de extensão é a quantidade de
tentativas
• Problemas
• Classe não é reutilizável
• Mudanças obrigam mudar o código fonte (o
que pode causar erros)

16. Liskov substitution principe
• Não se aplica. Não temos nenhuma subclasse.

17. Interface segregation
principle
• A interface da classe fica grande porque existe
muitas operações.

18. Dependency Inversion
• A classe cria objetos criando dependencias implicitas
• Problemas
• Dificulta a criação de testes unitários
• Impede a interceptação de chamadas
• Fixa módulos de alto nível com módulos de baixo
nível (quem toma decisões de negócio é a mesma
classe que trabalha com framework de envio de
email)

19. Vantagens
• Com S. criamos pequenos blocos de lógica
independentes
• Com O. permitimos que esses blocos sejam configuráveis
• Com L. garantimos que podemos alternar entre qualquer
um dos blocos sem quebrar o código
• Com I. criamos um padrão de blocos que são fácil de
serem construídos
• Com D. podemos configurar e montar da maneira que nos
for interessante

20. Criando os "blocos"

32. Conclusão
• O maior benefício não é no código que já existe,
mas sim na implementação de novas
funcionalidades
• Fazer S.O.L.I.D. é como brincar de LEGO, você
tem um monte de peças e só encaixa para formar
uma peça maior
• O resultado é um código simples, configurável,
com menor dependência de frameworks externos
e fácil de testar

33. Obrigado
• Dúvidas?