1. Princípios SOLID
Dyego Costa

2. { Princípios SOLID }

3. SRP
DIP OCP
SOLID
ISP LSP

4. Single
Responsibility
Dependency Open
Inversion
SOLID
Closed
Interface Liskov
Segregation Substitution

5. { Single Responsibility Principle
}
< SRP >
O princípio de responsabilidade única diz que todo objeto deve ter
uma única responsabilidade, e que a responsabilidade deve estar
encapsulada pela classe.
Nunca deve existir mais de um motivo para que uma classe mude.
Robert C. “Uncle Bob” Martin

6. Só porque você pode, não quer dizer que deve

7. { Acoplamento vs. Coesão }

8. coesão
A coesão é definida, em
termos acadêmicos, como a
medida de proximidade no
relacionamento entre todas as
responsabilidades, os dados e
os métodos de uma classe.
“maior = melhor”

9. acoplamento
O acoplamento entre classes
ou subsistemas é uma
medida da interconexão
entre essas classes ou
subsistemas.
“menor = melhor”

10. demonstração

11. { Open/Closed Principle }
< OCP >
O princípio Aberto/Fechado diz que
toda entidade de software
(classe, função, módulos, etc) deve estar
aberta para extensão e fechada para
modificação.

12. demonstração

13. { Liskov Substitution Principle }
< LSP >
“Se para cada objeto o¹ do tipo S existe um objeto o² do tipo T que
“Funções que usam referências para classes bases devem ser capazes
para todos programas P definidos em termos de T, o comportamento
de usar objetos de classes derivadas sem estar ciente disso.”
de P é imutável quando o¹ é substituído por o². Então S é um subtipo
de T.”
Robert C. “Uncle Bob” Martin
Barbara Liskov

14. { Regras }
 Pré-condições e pós-condições
Pré-condição não deve ser fortalecida e a
pós-condição não deve ser enfraquecida.
 Invariância
Se a condição de um processo é
verdadeiro na classe base deve
permanecer verdadeiro na subclasse.
 Histórico de contrato
As subclasses devem implementar todos
os membros de suas classes base.

15. { demonstração
}

16. { Interface Segregation Principle
}
< ISP >
O Princípio da Segregação de Interface afirma que os clientes não
deveriam ser forçados a depender de interfaces que eles não usam.

17. { demonstração
}

18. { Dependency Inversion
Principle }
< DIP >
Módulos de alto nível não devem depender de módulos de baixo nível. Ambos
devem depender de abstrações.
Em segundo lugar, abstrações não devem depender de detalhes.
Detalhes devem depender de abstrações.

19. demonstração

20. Containers de
Dependency Injection

21. { Referências / Dicas }
http://blackwasp.co.uk
http://dimecast.net
http://dofactory.com
http://pluralsight.com
http://codebetter.com