Keynote
Upcoming SlideShare
Loading in...5
×
 

Keynote

on

  • 262 views

 

Statistics

Views

Total Views
262
Views on SlideShare
262
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Keynote Keynote Presentation Transcript

  • Poro’s e Design Orientado a Objetos @thiagocifani xlsolutionssexta-feira, 8 de março de 13
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Falhas no Design • OOD falha quando o design está separado do ato de programar. • BUFDsexta-feira, 8 de março de 13
  • 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
  • sexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13
  • 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
  • sexta-feira, 8 de março de 13
  • Podemos melhorar dessa formasexta-feira, 8 de março de 13
  • Mas isso quebra o nosso testesexta-feira, 8 de março de 13
  • refactor!!!!!!sexta-feira, 8 de março de 13
  • refactor!!!!!!sexta-feira, 8 de março de 13
  • 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
  • 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
  • #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
  • Isolar a dependência em um método é boa prática para evitar um alto acoplamento.sexta-feira, 8 de março de 13
  • 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
  • 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
  • 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
  • sexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13
  • 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
  • Definimos 3 interfaces • Snife • Gunfire • Bombsexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13
  • 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
  • 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
  • sexta-feira, 8 de março de 13
  • 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
  • SuperClass Weaponsexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13
  • Evitando o super • Evite acoplamento ao chamar o super. • Utilize Hooks ou default_values methodssexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13
  • 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
  • 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
  • Diagramas de Sequênciasexta-feira, 8 de março de 13
  • 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
  • Law of Demeter • Métodos aninhados • Delegar • Evitar violaçõessexta-feira, 8 de março de 13
  • Perguntas?sexta-feira, 8 de março de 13
  • Obrigadosexta-feira, 8 de março de 13
  • 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
  • Books ◦ http://www.poodr.info/ ◦ http://objectsonrails.com/sexta-feira, 8 de março de 13
  • sexta-feira, 8 de março de 13