cocoaheads brasil sp - 26/04/16 - solid
TRANSCRIPT
S.O.L.I.D
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.
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
Single responsibility principe
• Uma classe deve ter apenas uma única responsabilidade.
• Responsabilidade = A classe só deve mudar por apenas um motivo
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.
Liskov substitution principe
• Subclasses devem conseguir ser usadas em qualquer local das classes pais.
• Subclasses não podem restringir o funcionamento de suas superclasses
Interface segregation principe
• Nenhuma classe deve implementar métodos que ela não precisa.
• Interfaces devem conter o mínimo necessários
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.
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.
Pseudo código
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
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
Nova especificação
• O modo antigo ainda vai continuar existindo
• Não se sabe se no futuro haverá outras mudanças desse tipo.
Single responsibility
• Enviar email
• Gerar log
• Realizar tentativas
• Formatar o email
• Escolher o tipo de método de envio
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)
Liskov substitution principe
• Não se aplica. Não temos nenhuma subclasse.
Interface segregation principle
• A interface da classe fica grande porque existe muitas operações.
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)
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
Criando os "blocos"
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
Obrigado
• Dúvidas?