cocoaheads brasil sp - 26/04/16 - solid

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?