Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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í...
S.O.L.I.D.
• S - Single responsibility principe
• O - Open-closed principe
• L - Liskov substitution principe
• I - Interf...
Single responsibility principe
• Uma classe deve ter apenas uma única
responsabilidade.
• Responsabilidade = A classe só d...
Open-closed principe
• Uma classe deve ser aberta para extensão e
fechada para modificação
• Devemos evitar ao máximo modifi...
Liskov substitution principe
• Subclasses devem conseguir ser usadas em
qualquer local das classes pais.
• Subclasses não ...
Interface segregation
principe
• Nenhuma classe deve implementar métodos
que ela não precisa.
• Interfaces devem conter o ...
Dependency inversion
principe
• Modulos de alto nível não devem depender de
modulos de baixo nível. Ambos devem
depender d...
Caso de Uso
• Cenário:
• Já existia um código com as seguintes especificações:
• Formatava os emails
• Enviava emails
• Era...
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....
Nova especificação
• Iria existir agora dois tipos de envio:
• A lógica de envio seria diferente porque seria
usado um novo...
Nova especificação
• O modo antigo ainda vai continuar existindo
• Não se sabe se no futuro haverá outras
mudanças desse ti...
Single responsibility
• Enviar email
• Gerar log
• Realizar tentativas
• Formatar o email
• Escolher o tipo de método de e...
Open-closed
• O único ponto de extensão é a quantidade de
tentativas
• Problemas
• Classe não é reutilizável
• Mudanças ob...
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 un...
Vantagens
• Com S. criamos pequenos blocos de lógica
independentes
• Com O. permitimos que esses blocos sejam configuráveis...
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...
Obrigado
• Dúvidas?
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Cocoaheads Brasil SP - 26/04/16 - SOLID
Upcoming SlideShare
Loading in …5
×

Cocoaheads Brasil SP - 26/04/16 - SOLID

164 views

Published on

Use case of refactoring to solid principles

Published in: Technology
  • Hello! Who wants to chat with me? Nu photos with me here http://bit.ly/helenswee
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Cocoaheads Brasil SP - 26/04/16 - SOLID

  1. 1. S.O.L.I.D
  2. 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. 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. 4. Single responsibility principe • Uma classe deve ter apenas uma única responsabilidade. • Responsabilidade = A classe só deve mudar por apenas um motivo
  5. 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. 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. 7. Interface segregation principe • Nenhuma classe deve implementar métodos que ela não precisa. • Interfaces devem conter o mínimo necessários
  8. 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. 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. 10. Pseudo código
  11. 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. 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. 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. 14. Single responsibility • Enviar email • Gerar log • Realizar tentativas • Formatar o email • Escolher o tipo de método de envio
  15. 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. 16. Liskov substitution principe • Não se aplica. Não temos nenhuma subclasse.
  17. 17. Interface segregation principle • A interface da classe fica grande porque existe muitas operações.
  18. 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. 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. 20. Criando os "blocos"
  21. 21. 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
  22. 22. Obrigado • Dúvidas?

×