Princípios SOLID

406 visualizações

Publicada em

Apresentação de SOLID para a equipe de desenvolvimento da WebCasters

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
406
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
12
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Princípios SOLID

  1. 1. S.O.L.I.D. Princípios de Design para Programação Orientada a Objetos
  2. 2. O Código Apodrece  Inevitável  Exemplo de correção de bug  Acoplamento  Mudança em uma linha de código gera mudanças em outras tantas  Nós temos que nos munir de armas contra o apodrecimento do código  SOLID é uma das armas
  3. 3. S.O.L.I.D. Desenvolvimento de Sistemas não é um jogo Jenga
  4. 4. Princípios  Single Responsibility Principle  Princípio de Responsabilidade Única  Open Closed Principle  Princípio Aberto Fechado  Liskov Substitution Principle  Princípio da Substituição de Liskov  Interface Segregation Principle  Princípio da Segregação de Interface  Dependency Inversion Principle  Princípio da Inversão de Dependência
  5. 5. Vantagens  Fácil de manter, adaptar e ajustar às constantes mudanças exigidas pelos clientes  Fácil de entender e testar  Menor esforço para manutenções  Melhor reaproveitamento de código
  6. 6. Princípio de Responsabilidade Única Todo objeto deve ter uma única responsabilidade, e todos os seus serviços devem estar rigorosamente alinhados com aquela responsabilidade.
  7. 7. Princípio de Responsabilidade Única  Sintomas quando o princípio não é seguido:  Quantas vezes abrimos um código e simplesmente não temos a mínima ideia do que ele está fazendo?  Quantas variáveis espalhadas, aparentemente sem sentido?  Quantos cálculos mentais temos que fazer para descobrir se vai entrar naquele IF?  E quando a barra de rolagem parece não ter fim?
  8. 8. Princípio de Responsabilidade Única  Uma classe ou método deve ter uma e apenas uma razão para mudar  Quebrando o princípio:  TransmissaoRepositorio  Seguindo o princípio:  TransmissaoRepositorio  ConversorTransmissao  ControladorDiscoRigido  ControladorEmail
  9. 9. Princípio Aberto Fechado Cirurgia de peito aberto não é necessário ao colocar um casaco.
  10. 10. Princípio Aberto Fechado  Sintomas quando o princípio não é seguido:  Adicionar novas regras requer mudança sempre no mesmo pedaço de código  Cada mudança pode introduzir bugs e requer novos testes  Mudar um pedaço de código cria mudança em cascata em várias classes.  If-ElseIf-Else encadeados  Switch-Case
  11. 11. Princípio Aberto Fechado  Aberto para extensão  Novo comportamento pode ser adicionado no futuro  Fechado para modificação  Não há necessidade de modificar o código  Como adicionar novo comportamento sem mudar o código?  Depender de abstrações: Interfaces ou Classes Abstratas
  12. 12. Princípio Aberto Fechado  Quebrando o princípio:  Carrinho  Seguindo o princípio:  Carrinho  CalculadorPreco  IRegraPreco  RegraPrecoEspecial  RegraPrecoPorGrama  RegraPrecoCada
  13. 13. Substituição de Liskov Caso se pareça um pato e grasne como um pato mas precise de baterias, você provavelmente possui a abstração errada.
  14. 14. Substituição de Liskov  Os subtipos devem ser substituíveis pelos seus tipos base.  Sintoma quando o princípio não é seguido:  Usar o operador “is” ou “typeof” em condições if- else ou switch
  15. 15. Substituição de Liskov  Quebrando o princípio:  Retangulo  Quadrado  Seguindo o princípio:  Forma  Retangulo  Quadrado  Quadrado só é um retângulo no mundo real. Essa abstração “é-um” nesse caso não é válida.
  16. 16. Segregação de Interface Você quer que eu plugue isso onde?
  17. 17. Segregação de Interface  Clientes não devem ser forçados a dependerem de métodos que eles não usam  Sintomas quando o princípio não é seguido:  Interfaces com vários métodos, “gordas”  Quebra o princípio de Responsabilidade Única  Implementar uma interface “gorda” e nos métodos que não quer implementar lançar uma exceção  Por exemplo: método não suportado  Ou throw new NotImplementedException()
  18. 18. Segregação de Interface  Quebrando o princípio  Contato  ControladorEmail  Discador  Seguindo o princípio:  IDiscavel  IEmail  Contato  ControladorEmail  Discador
  19. 19. Inversão de Dependência Você soldaria uma lâmpada diretamente no fio de eletricidade na parede?
  20. 20. Inversão de Dependência  Um módulo de alto nível não deve depender de outros de baixo nível  Baixo nível: acesso a banco, arquivos, WebServices  Alto nível: regras e entidades de negócio, interação com usuário  Módulos de alto nível devem utilizar um mecanismo para obter os dados de baixo nível, mas não depender dos detalhes desse mecanismo  UI depender do módulo de persistência, por exemplo banco de dados  Se a persistência mudar para arquivo Xml, toda a UI terá que ser reescrita
  21. 21. Inversão de Dependência  Sintomas:  Dentro de um módulo/classe/método instanciar uma classe explicitamente usando o operador “new”  Possuir referência do projeto de acesso a dados no projeto de UI  O ideal é sempre depender de abstrações: Interfaces ou classes abstratas
  22. 22. Inversão de Dependência TransmissaoReposit orio ControladorEmail ConversorTransmis sao
  23. 23. Inversão de Dependência TransmissaoReposit orio IControladorEmail IConversorTransmis sao ConversorTransmis sao ControladorEmail
  24. 24. Inversão de Dependência  Aplicando o princípio nos exemplos:  SingleResponsibility  OpenClosed
  25. 25. Referências  Software Practices, Pluralsight  Principles of Object Oriented Design  Design Patterns  Clean Code A Handbook of Agile Software Craftsmanship, Robert C. Martin  Agile Principles, Patterns, and Practices in C#, Robert C. Martin

×