O documento discute a importância da Orientação a Objetos (OO) e dos princípios SOLID para o desenvolvimento de software. A OO permite modelar o mundo real através de classes e objetos e esconder detalhes de implementação. Os princípios SOLID promovem responsabilidades bem definidas, menor acoplamento e maior reusabilidade do código.

1. OO e
SOLID
Janderson
Thomaz

2. Sistemas de Informação
Analista Programador na
DETIC – Governo de
Rondônia
Palmeirense....
Pregador da Orientação a
Objetos

3. Nem tudo é perfeito, né?

5. Uma historinha...

9. Por que eu preciso entender
Orientação a Objetos?

10. POG
É muito mais difícil do que parece;
Muito se fala em OO;
Código procedural.

11. Nem tudo é perfeito, né?
Paradigma(Estilo) de programação;
Pensar no mundo real;
Modelar domínios;
Abstração.

12. Nem tudo é perfeito, né?

13. Nem tudo é perfeito, né?
Pra que esse
setSaldo?
Pra que esse
setLimite?

14. Use comportamentos e faça
encapsulamento de suas regras

15. Nem tudo é perfeito, né?

16. Nem tudo é perfeito, né?
Classes devem ter dados e
comportamentos(ações)
Dados = Atributos
Comportamentos = Métodos
Comportamento deve alterar o estado do
atributo

17. Classes devem esconder COMO ela faz sua
tarefa

18. Evite o Modelo Anêmico

19. Dados separados
de
comportamentos
A classe Nota
Fiscal deve saber
como ENCERRAR

20. Tell, Don’t Ask (Diga, não pergunte)

21. ifs são perguntas que fazemos ao
objeto.

22. Dar ordens ao
objeto.

23. IF Hadouken

25. Bad Code ou código ruim mesmo....

28. Métodos longos Muitos ifs
Código repetido Sem padrão
Classes gigantes Muitos paramentos

29. Commad Query Saparation

30. Ou o método faz alguma coisa, ou devolve
alguma coisa.
Nunca os dois.

31. Código Bonito ou Clean Code ou
Código Limpo

32. Pensar em nomes

34. var chora;
//Carga horária
WTF?

35. Deve dizer o
que ele faz
Deve fácil de
ser entendido
É mais importante do
que você imagina

36. Evite nomes
parecidos

37. Nomes
pronunciáveis

38. SOLID

40. Single Responsibility Principle

41. Uma classe deve ter uma, apenas
uma, razão para mudar - SRP

43. Classes devem ser coesas
e ter baixo acoplamento

44. Open Closed Principle

45. Abertas para extensão,
mas fechadas para
modificação.

46. Liskov Substitution Principle

47. Se para cada objeto o1 do tipo S há um
objeto o2 do tipo T de forma que, para
todos os programas P definidos em
termos de T, o comportamento de P é
inalterado quando o1 é substituído por
o2 então S é um subtipo de T.

49. Classes derivadas devem
poder ser substituídas por
suas classes base.

50. Interface Segregation Principle

51. Muitas interfaces específicas
são melhores do que uma
interface geral;
Clientes não devem ser
forçados a depender de
métodos que não usam.

52. Dependency Inversion Principle

53. Módulos de alto nível não devem
depender de módulos de baixo nível.
Ambos devem depender de
abstrações;
Abstrações não devem depender de
detalhes. Detalhes devem depender
de abstrações.

54. Conclusão

55. Responsabilidades bem definidas;
Menor propagação de erros e
mudanças;
Fácil de manter;
Boas práticas!
Tem que praticar...

56. Pensar na implementação é
importante, mas pensar no design
de classes é fundamental.

58. Obrigado!
jandersoncthomaz@gmail.com