Keynote

  • Published on
    28-May-2015

  • View
    183

  • Download
    0

Transcript

  • 1. Poro’s e Design Orientado a Objetos @thiagocifanixlsolutionssexta-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 permitindoque sejam criadas classes para definir objetosreais. Numa linguagem procedural, os passos sãosequências e pré-definidos, já um objeto podepossuir vários comportamentos e mudar deacordo 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 daapresentaçã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 passbetween objects. POODSandi Metzsexta-feira, 8 de março de 13 6. OOD• Software sempre mudará• Design facilita as alterações e mudançasque o código receberá.• Um bom programador pensa num designda aplicação que poderá ou não sofrermudanças num futuro.sexta-feira, 8 de março de 13 7. Bad Smells• Se eu escrever essa feature a aplicação vaiquebrar• Eu não posso criar essa feature, a app nãofoi pensada dessa forma.sexta-feira, 8 de março de 13 8. Falhas no Design• OOD falha quando o design está separado do atode programar.• BUFDsexta-feira, 8 de março de 13 9. Aplicações Monolíticas• A aplicação é acoplada de diversas formas asuas tarefas.• Não existe separação do trabalho eresponsabilidades, sendo de classes oufunçõ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ãodifíceis de usar, pois as mesmas estão relacionadascom outras classes num nível muito profundo.• No código anterior, e se fosse necessário usarapenas os usuário isoladamente? Necessitariainstanciar 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 asresponsabilidades de cada classe oumétodo ajuda a fazer código acoplado.• #harm deve pertencer a player? E gun?Aparemente para saber o dano, devemospossuir uma arma para tal.Vamosremodelar.sexta-feira, 8 de março de 13 20. #Harm• A meu ver harm é um método que recebedois players e não está no escopo da classegame, por outro lado, não está no escopode player também. Então vamos separar emuma classe especifica.sexta-feira, 8 de março de 13 21. Isolar a dependência em um método é boaprática para evitar um alto acoplamento.sexta-feira, 8 de março de 13 22. TextSe preocupe apenas com a interface que o player vai responder enquanto você testa. Vamosmockar a classe Attack.sexta-feira, 8 de março de 13 23. O código do teste só verifica seexiste 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 quegun 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 tiposde armas, cada uma com um dano. No nosso novodesign, tiramos o código da classe game e criamosPlayer.• Para fazer um ataque, criamos outra classechamada attack, e injetamos os jogadores, masnosso design diz que jogador tem uma arma, entãovamos 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 TypingIf a object quacks like a duck and walks like a duck, the its class isimmaterial, its a duck.POODsexta-feira, 8 de março de 13 32. Duck Typing• Pensando em evitar dependências, devemosdesenvolver códigos menos acoplados eapis públicas mais estáveis.• Devemos evitar usar os métodos #kind_of,#respond_to e passar a confiar em nossasimplementaçõ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 decompartilhar código genérico com as filhas• Facilitar a criação de futuras subclassesusando 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_valuesmethodssexta-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 osobjetos que ela interaje que a classe ao invés deusar uma api para executar algo em outro, ela dizpara a outra como fazer.• Classes que tem responsabilidade única sãoespecialistas no que fazem, ou seja, sabem muitobem como executar tal método, apneas recebendoos devidos argumentossexta-feira, 8 de março de 13 41. What - How• Player pode conhecer ataque, mas não temnecessidade de saber como o ataque écalculado, e quanto vale os ataques dearmas 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, queentende os argumentos e gera um dano noanother_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