Keynote

  • 154 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
154
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Poro’s e Design Orientado a Objetos @thiagocifani xlsolutionssexta-feira, 8 de março de 13
  • 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. 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. 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. 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. 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. 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. Falhas no Design • OOD falha quando o design está separado do ato de programar. • BUFDsexta-feira, 8 de março de 13
  • 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. sexta-feira, 8 de março de 13
  • 11. sexta-feira, 8 de março de 13
  • 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. sexta-feira, 8 de março de 13
  • 14. Podemos melhorar dessa formasexta-feira, 8 de março de 13
  • 15. Mas isso quebra o nosso testesexta-feira, 8 de março de 13
  • 16. refactor!!!!!!sexta-feira, 8 de março de 13
  • 17. refactor!!!!!!sexta-feira, 8 de março de 13
  • 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. 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. #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. 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. 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. 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. 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. sexta-feira, 8 de março de 13
  • 26. sexta-feira, 8 de março de 13
  • 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. Definimos 3 interfaces • Snife • Gunfire • Bombsexta-feira, 8 de março de 13
  • 29. sexta-feira, 8 de março de 13
  • 30. sexta-feira, 8 de março de 13
  • 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. 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. sexta-feira, 8 de março de 13
  • 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. SuperClass Weaponsexta-feira, 8 de março de 13
  • 36. sexta-feira, 8 de março de 13
  • 37. sexta-feira, 8 de março de 13
  • 38. Evitando o super • Evite acoplamento ao chamar o super. • Utilize Hooks ou default_values methodssexta-feira, 8 de março de 13
  • 39. sexta-feira, 8 de março de 13
  • 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. 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. Diagramas de Sequênciasexta-feira, 8 de março de 13
  • 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. Law of Demeter • Métodos aninhados • Delegar • Evitar violaçõessexta-feira, 8 de março de 13
  • 45. Perguntas?sexta-feira, 8 de março de 13
  • 46. Obrigadosexta-feira, 8 de março de 13
  • 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. Books ◦ http://www.poodr.info/ ◦ http://objectsonrails.com/sexta-feira, 8 de março de 13
  • 49. sexta-feira, 8 de março de 13