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
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
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
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.
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
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
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