O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Orientação a Objetos e SOLID

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
3e88de98635b6c (1)
3e88de98635b6c (1)
Carregando em…3
×

Confira estes a seguir

1 de 58 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Mais recentes (20)

Anúncio

Orientação a Objetos e SOLID

  1. 1. OO e SOLID Janderson Thomaz
  2. 2. Sistemas de Informação Analista Programador na DETIC – Governo de Rondônia Palmeirense.... Pregador da Orientação a Objetos
  3. 3. Nem tudo é perfeito, né?
  4. 4. Uma historinha...
  5. 5. Por que eu preciso entender Orientação a Objetos?
  6. 6. POG É muito mais difícil do que parece; Muito se fala em OO; Código procedural.
  7. 7. Nem tudo é perfeito, né? Paradigma(Estilo) de programação; Pensar no mundo real; Modelar domínios; Abstração.
  8. 8. Nem tudo é perfeito, né?
  9. 9. Nem tudo é perfeito, né? Pra que esse setSaldo? Pra que esse setLimite?
  10. 10. Use comportamentos e faça encapsulamento de suas regras
  11. 11. Nem tudo é perfeito, né?
  12. 12. Nem tudo é perfeito, né? Classes devem ter dados e comportamentos(ações) Dados = Atributos Comportamentos = Métodos Comportamento deve alterar o estado do atributo
  13. 13. Classes devem esconder COMO ela faz sua tarefa
  14. 14. Evite o Modelo Anêmico
  15. 15. Dados separados de comportamentos A classe Nota Fiscal deve saber como ENCERRAR
  16. 16. Tell, Don’t Ask (Diga, não pergunte)
  17. 17. ifs são perguntas que fazemos ao objeto.
  18. 18. Dar ordens ao objeto.
  19. 19. IF Hadouken
  20. 20. Bad Code ou código ruim mesmo....
  21. 21. Métodos longos Muitos ifs Código repetido Sem padrão Classes gigantes Muitos paramentos
  22. 22. Commad Query Saparation
  23. 23. Ou o método faz alguma coisa, ou devolve alguma coisa. Nunca os dois.
  24. 24. Código Bonito ou Clean Code ou Código Limpo
  25. 25. Pensar em nomes
  26. 26. var chora; //Carga horária WTF?
  27. 27. Deve dizer o que ele faz Deve fácil de ser entendido É mais importante do que você imagina
  28. 28. Evite nomes parecidos
  29. 29. Nomes pronunciáveis
  30. 30. SOLID
  31. 31. Single Responsibility Principle
  32. 32. Uma classe deve ter uma, apenas uma, razão para mudar - SRP
  33. 33. Classes devem ser coesas e ter baixo acoplamento
  34. 34. Open Closed Principle
  35. 35. Abertas para extensão, mas fechadas para modificação.
  36. 36. Liskov Substitution Principle
  37. 37. 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.
  38. 38. Classes derivadas devem poder ser substituídas por suas classes base.
  39. 39. Interface Segregation Principle
  40. 40. 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.
  41. 41. Dependency Inversion Principle
  42. 42. 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.
  43. 43. Conclusão
  44. 44. Responsabilidades bem definidas; Menor propagação de erros e mudanças; Fácil de manter; Boas práticas! Tem que praticar...
  45. 45. Pensar na implementação é importante, mas pensar no design de classes é fundamental.
  46. 46. Obrigado! jandersoncthomaz@gmail.com

×