princípios s.o.l.i.d

Princípios S.O.L.I.D.Leandro Nishijima

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!