Keynote

302 views
255 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
302
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Keynote

  1. 1. Poro’s e Design Orientado a Objetos @thiagocifani xlsolutionssexta-feira, 8 de março de 13
  2. 2. Agenda • Orientação a Objetos • Duck Typing • Law of Demeter • Single Responsability Principle • Injeção de Dependências • Pure Old Ruby Objectssexta-feira, 8 de março de 13
  3. 3. Design Orientado a Objetos • A OO facilita a vida do desenvolvedor permitindo que sejam criadas classes para definir objetos reais. Numa linguagem procedural, os passos são sequências e pré-definidos, já um objeto pode possuir vários comportamentos e mudar de acordo com as mensagens recebidas.sexta-feira, 8 de março de 13
  4. 4. Disclaimer • Onde está escrito Snife, por favor, considerar Knife. Eu fiz o slide no dia da apresentação e não vi esse erro bizarro. :)sexta-feira, 8 de março de 13
  5. 5. Object Oriented Design (OOD) requires that you shift from thinking of the world as a collection of predefined procedures to modeling the world as a series of messages that pass between objects. POOD Sandi Metzsexta-feira, 8 de março de 13
  6. 6. OOD • Software sempre mudará • Design facilita as alterações e mudanças que o código receberá. • Um bom programador pensa num design da aplicação que poderá ou não sofrer mudanças num futuro.sexta-feira, 8 de março de 13
  7. 7. Bad Smells • Se eu escrever essa feature a aplicação vai quebrar • Eu não posso criar essa feature, a app não foi pensada dessa forma.sexta-feira, 8 de março de 13
  8. 8. Falhas no Design • OOD falha quando o design está separado do ato de programar. • BUFDsexta-feira, 8 de março de 13
  9. 9. Aplicações Monolíticas • A aplicação é acoplada de diversas formas a suas tarefas. • Não existe separação do trabalho e responsabilidades, sendo de classes ou funções.sexta-feira, 8 de março de 13
  10. 10. sexta-feira, 8 de março de 13
  11. 11. sexta-feira, 8 de março de 13
  12. 12. SR é importante • Aplicações que são fáceis em receber mudanças, consistem em classes que são fáceis de reusar. (POOD) • Classes que tem muita responsabilidade são difíceis de usar, pois as mesmas estão relacionadas com outras classes num nível muito profundo. • No código anterior, e se fosse necessário usar apenas os usuário isoladamente? Necessitaria instanciar Game.sexta-feira, 8 de março de 13
  13. 13. sexta-feira, 8 de março de 13
  14. 14. Podemos melhorar dessa formasexta-feira, 8 de março de 13
  15. 15. Mas isso quebra o nosso testesexta-feira, 8 de março de 13
  16. 16. refactor!!!!!!sexta-feira, 8 de março de 13
  17. 17. refactor!!!!!!sexta-feira, 8 de março de 13
  18. 18. O teste me diz algo sobre o design. Será que decrementar a vida é o correto? ou o método harm deve pertencer a player?sexta-feira, 8 de março de 13
  19. 19. Responsabilidades dispersas • Codificar sem se preocupar com as responsabilidades de cada classe ou método ajuda a fazer código acoplado. • #harm deve pertencer a player? E gun? Aparemente para saber o dano, devemos possuir uma arma para tal.Vamos remodelar.sexta-feira, 8 de março de 13
  20. 20. #Harm • A meu ver harm é um método que recebe dois players e não está no escopo da classe game, por outro lado, não está no escopo de player também. Então vamos separar em uma classe especifica.sexta-feira, 8 de março de 13
  21. 21. Isolar a dependência em um método é boa prática para evitar um alto acoplamento.sexta-feira, 8 de março de 13
  22. 22. Text Se preocupe apenas com a interface que o player vai responder enquanto você testa. Vamos mockar a classe Attack.sexta-feira, 8 de março de 13
  23. 23. O código do teste só verifica se existe a chamada ao método, todo o processo de teste deve ser feito no PORO Attack.sexta-feira, 8 de março de 13
  24. 24. Attack • Analisando o design, é fácil perceber que gun não deve ser passado por parâmetro, pois player deve ter uma arma.sexta-feira, 8 de março de 13
  25. 25. sexta-feira, 8 de março de 13
  26. 26. sexta-feira, 8 de março de 13
  27. 27. Weapon • Aparentemente no CS podemos ter vários tipos de armas, cada uma com um dano. No nosso novo design, tiramos o código da classe game e criamos Player. • Para fazer um ataque, criamos outra classe chamada attack, e injetamos os jogadores, mas nosso design diz que jogador tem uma arma, então vamos separar essa definicão em uma classe.sexta-feira, 8 de março de 13
  28. 28. Definimos 3 interfaces • Snife • Gunfire • Bombsexta-feira, 8 de março de 13
  29. 29. sexta-feira, 8 de março de 13
  30. 30. sexta-feira, 8 de março de 13
  31. 31. Duck Typing If a object quacks like a duck and walks like a duck, the its class is immaterial, its a duck. POODsexta-feira, 8 de março de 13
  32. 32. Duck Typing • Pensando em evitar dependências, devemos desenvolver códigos menos acoplados e apis públicas mais estáveis. • Devemos evitar usar os métodos #kind_of, #respond_to e passar a confiar em nossas implementações.sexta-feira, 8 de março de 13
  33. 33. sexta-feira, 8 de março de 13
  34. 34. Herança • Tornar as superclasses abstratas ao nível de compartilhar código genérico com as filhas • Facilitar a criação de futuras subclasses usando um template bem estruturado. (template method pattern)sexta-feira, 8 de março de 13
  35. 35. SuperClass Weaponsexta-feira, 8 de março de 13
  36. 36. sexta-feira, 8 de março de 13
  37. 37. sexta-feira, 8 de março de 13
  38. 38. Evitando o super • Evite acoplamento ao chamar o super. • Utilize Hooks ou default_values methodssexta-feira, 8 de março de 13
  39. 39. sexta-feira, 8 de março de 13
  40. 40. Perguntar ao invés de dizer como faz • Algumas das nossas classes sabem tanto sobre os objetos que ela interaje que a classe ao invés de usar uma api para executar algo em outro, ela diz para a outra como fazer. • Classes que tem responsabilidade única são especialistas no que fazem, ou seja, sabem muito bem como executar tal método, apneas recebendo os devidos argumentossexta-feira, 8 de março de 13
  41. 41. What - How • Player pode conhecer ataque, mas não tem necessidade de saber como o ataque é calculado, e quanto vale os ataques de armas específicas.sexta-feira, 8 de março de 13
  42. 42. Diagramas de Sequênciasexta-feira, 8 de março de 13
  43. 43. OOD - aplicação baseada em mensagens • Player envia mensagem para attack, que entende os argumentos e gera um dano no another_player que fora atacado.sexta-feira, 8 de março de 13
  44. 44. Law of Demeter • Métodos aninhados • Delegar • Evitar violaçõessexta-feira, 8 de março de 13
  45. 45. Perguntas?sexta-feira, 8 de março de 13
  46. 46. Obrigadosexta-feira, 8 de março de 13
  47. 47. Links Uteis ◦ http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord- models/ ◦ http://confreaks.com/videos/240-goruco2009-solid-object-oriented-design ◦ http://confreaks.com/videos/185-rubyconf2009-solid-ruby ◦ http://caironoleto.com/2012/04/15/poro-pure-old-ruby-object/sexta-feira, 8 de março de 13
  48. 48. Books ◦ http://www.poodr.info/ ◦ http://objectsonrails.com/sexta-feira, 8 de março de 13
  49. 49. sexta-feira, 8 de março de 13

×