Princípios SOLID
•Download as PPTX, PDF•
0 likes•577 views
Apresentação de SOLID para a equipe de desenvolvimento da WebCasters
Recommended
More Related Content
Viewers also liked
Viewers also liked (7)
Similar to Princípios SOLID
Similar to Princípios SOLID (20)
Princípios SOLID
- 1. S.O.L.I.D. Princípios de Design para Programação Orientada a Objetos
- 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. S.O.L.I.D. Desenvolvimento de Sistemas não é um jogo Jenga
- 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. 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. 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. 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. 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. Princípio Aberto Fechado Cirurgia de peito aberto não é necessário ao colocar um casaco.
- 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. 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. Princípio Aberto Fechado Quebrando o princípio: Carrinho Seguindo o princípio: Carrinho CalculadorPreco IRegraPreco RegraPrecoEspecial RegraPrecoPorGrama RegraPrecoCada
- 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. 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. 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. Segregação de Interface Você quer que eu plugue isso onde?
- 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. Segregação de Interface Quebrando o princípio Contato ControladorEmail Discador Seguindo o princípio: IDiscavel IEmail Contato ControladorEmail Discador
- 19. Inversão de Dependência Você soldaria uma lâmpada diretamente no fio de eletricidade na parede?
- 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. 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
- 24. Inversão de Dependência Aplicando o princípio nos exemplos: SingleResponsibility OpenClosed
- 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