Keynote

Poro’s e Design Orientado a Objetos
@thiagocifani
xlsolutions

sexta-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 Objects

Design Orientado a Objetos

• A OO facilita a vida do desenvolvedor permitindo
que sejam criadas classes para deﬁnir objetos
reais. Numa linguagem procedural, os passos são
sequências e pré-deﬁnidos, já um objeto pode
possuir vários comportamentos e mudar de
acordo com as mensagens recebidas.


Disclaimer

• Onde está escrito Snife, por favor,
considerar Knife. Eu ﬁz o slide no dia da
apresentação e não vi esse erro bizarro. :)


Object Oriented Design (OOD) requires that you shift from
thinking of the world as a collection of predeﬁned procedures
to modeling the world as a series of messages that pass
between objects.

POOD
Sandi Metz


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.


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.


Falhas no Design

• OOD falha quando o design está separado do ato
de programar.

• BUFD


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.


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.


Podemos melhorar dessa forma


Mas isso quebra o nosso teste


refactor!!!!!!

O teste me diz algo sobre o design. Será que
decrementar a vida é o correto? ou o método harm
deve pertencer a player?


Responsabilidades dispersas

• Codiﬁcar 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.


#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 especiﬁca.


Isolar a dependência em um método é boa
prática para evitar um alto acoplamento.


Text

Se preocupe apenas com a interface que o player
vai responder enquanto você testa. Vamos
mockar a classe Attack.


O código do teste só veriﬁca se
existe a chamada ao método,
todo o processo de teste deve
ser feito no PORO Attack.


Attack

• Analisando o design, é fácil perceber que
gun não deve ser passado por parâmetro,
pois player deve ter uma arma.


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 deﬁnicão em uma classe.


Deﬁnimos 3 interfaces

• Snife
• Gunﬁre
• Bomb


Duck Typing

If a object quacks like a duck and
walks like a duck, the its class is
immaterial, its a duck.

POOD


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 conﬁar em nossas
implementações.


Herança

• Tornar as superclasses abstratas ao nível de
compartilhar código genérico com as ﬁlhas
• Facilitar a criação de futuras subclasses
usando um template bem estruturado.
(template method pattern)


SuperClass Weapon

Evitando o super

• Evite acoplamento ao chamar o super.
• Utilize Hooks ou default_values
methods


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 argumentos


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íﬁcas.


Diagramas de Sequência

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.


Law of Demeter

• Métodos aninhados
• Delegar
• Evitar violações


Perguntas?


Obrigado


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/


Books
◦ http://www.poodr.info/
◦ http://objectsonrails.com/


Keynote

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Empfohlen

Empfohlen (20)

Keynote