princípios s.o.l.i.d
TRANSCRIPT
Por que sistemas orientados a objetos são tão difíceis de se trabalhar?
Dificuldades
- Propagação de problemas?
- Dificuldade de criar testes?
- Refactorings sofríveis?
- Instabilidades de classes?
- Dificuldades de modularização do projeto?
- Retrabalho?
- ∞
Princípios S.O.L.I.D.
Origem
Criados por Michael Feathers nos
anos 2000. Através de observações
de arquiteturas de projetos OO
Popularizados por
Robert C. Martin
S.O.L.I.D. ?
S.O.L.I.D. ?
Single Responsability Principle“Uma classe deve ter uma, e apenas uma razão para mudar.”
- SRP == Coesão
- Classes devem ter apenas uma
responsabilidades;
- Implementado de maneira
correta, cada objeto terá
apenas uma razão para mudar.
- Builders são um bom exemplo
de classes que utilizam SRP.
Exemplo clichê “Head First: Object-Oriented Analysis & Design.”
- SRP == Coesão
- Classes devem ter apenas uma
responsabilidades;
- Implementado de maneira
correta, cada objeto terá
apenas uma razão para mudar;
- Builders são um bom exemplo
de classes que utilizam SRP.
Exemplo clichê “Head First: Object-Oriented Analysis & Design.”
Open and Closed Principle“Uma classe deve ser aberta para a extensão, mas fechada para a
modificação.”
- Refere-se a permissão de
mudanças;
- Porém sem necessariamente
modificando um código
existente;
- Crie classes de forma que
você crie ramos de
modificações.
- O Design Pattern Strategy é
um excelente exemplo da
aplicação correta do princípio.
Liskov Substitution Principle“Classes derivadas devem ser substituíveis pela sua classe base.”
Liskov?“O princípio foi inspirado através de um artigo escrito por Barbara
Liskov sobre Hoare Logic”
- Uso adequado da herança
entre as classes;
- Nunca deve-se quebrar o
contrato de uma classe pai!
- Nunca apertar pré condições;
- Nunca afrouxar pós
condições.
Exemplo de quebra de contrato da classe pai.
Resumindo LSP em uma frase.
Interface Segregation Principle“Interfaces devem ser simples e com poucos comportamentos.”
- Referencia diretamente ao
acoplamento entre as classes
- Interfaces ao ser
implementadas não devem
forçar comportamentos que
outras classes não precisem!
Template Method
Resumindo ISP em uma imagem.
Dependency Inversion Principle“Dependa de abstrações e não de implementações.”
- Uma classe sempre deve
depender de classes que sejam
mais estáveis que ela mesma.
- Classes devem depender de
abstrações.
- Desenvolver seguindo o DIP é:
“Pensar primeiro na abstrações de suas
classes, e depois, na implementação.”
Quais as vantagens da adoção dos
princípios a curto prazo?
Métricas finais do projeto de TCC ( github)
E a longo prazo?
E a longo prazo?
E a longo prazo?Classes flexíveis e genéricas o suficiente para desenvolver OO
utilizando composição.
Se aprofundeUncle Bob: SOLID Principles of Object Oriented And Agile Design
https://youtu.be/TMuno5RZNeE
Steve Freeman & Nat Pryce: Building on SOLID fundations
https://youtu.be/6Bia81dI-JE
Leia os livros:
Obrigado!