OOP Hipster – Conceitos de OO fora do
mainstream que todo programador deveria
entender
Renan Ranelli, 02/2015
Slide 2
Slide 2 text
●
Objetivo:
– Apresentar as idéias que deram origem ao movimento
de OOP
– Separar o que é fundamental em OO do que é
acidental.
– Identificar os princípios básicos que devem guiar o
design de software OO, com ou sem o apoio da sua
linguagem de programação
– Entender que OO não diz respeito a classes e
métodos.
Slide 3
Slide 3 text
Qual o significa de Orientação a objetos??
Slide 4
Slide 4 text
Alan Kay responde:
Slide 5
Slide 5 text
●
What does OOP mean?
– To me, OO means only messaging, local
retention and protection, hiding of state-
process, and extreme late-binding of all things. It
can be done in Smalltalk and Lisp.
Slide 6
Slide 6 text
●
How did you get to “discover” OOP ?
– I thought of objects being like biological cells
and/or individual computers on a network only
able to communicate with messages …
– It was really important for me to finally understand
LISP and then using this understanding make
much nicer and smaller and more powerful late
bound under-structures.
Slide 7
Slide 7 text
●
Notaram?
– Não há menção a polimorfismo, herança, classes,
interfaces, métodos, yadda yadda.
●
Um objeto não conhece nada a respeito de como
funciona outro objeto.
●
Um objeto não consegue fazer nada além de
reter o próprio estado e enviar mensagens a
outros objetos.
●
Portanto, é impossível um objeto alterar seu
estado sem antes ter recebido uma mensagem
Slide 11
Slide 11 text
●
Agora... como o objeto sabe o que fazer
quando recebe uma mensagem ?
●
A função de despacho (dispatch function) é
quem decide qual função/procedimento
deverá ser invocada de acordo com a
mensagem recebida.
Slide 12
Slide 12 text
●
Nas linguagens que tem suporte a OO, a
função de despacho é algo escondido, interno
ao runtime.
●
A função de despacho fica cada vez mais
complicada quando começamos a embutir
suporte a polimorfismo, herança e tipos na
linguagem.
Slide 13
Slide 13 text
●
Exemplo:
Slide 14
Slide 14 text
●
Exemplo:
Slide 15
Slide 15 text
●
Exemplo:
Slide 16
Slide 16 text
●
As mensagens definem a colaboração dos
objetos. Mensagens especificam a semantica
do funcionamento do sistema
●
Métodos definem o controle de fluxo e as
instruções que a máquina deve executar para
responder uma mensagem. Vários métodos
podem responder uma mesma mensagem, e
(deveriam) obedecem a semantica da mesma
Slide 17
Slide 17 text
●
O conjunto de mensagens que um objeto
responde especifica completamente todos os
contextos em que ele pode ser usado.
●
Se dois objetos respondem ao mesmo
conjunto de mensagens, nenhum terceiro
objeto seria capaz de distringuir esses dois
objetos. Isso tem um nome: encapsulamento
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
●
Podemos então dizer que esse conjunto de
mensagens define uma *interface* que deve
ser respeitada por objetos inter-substituíveis
●
A derivação de *classificações* e *hierarquias*
de objetos fica então a cargo do ouvinte ;)
Slide 20
Slide 20 text
●
Bonus
– Se você grokar a idéia de mensagens e objetos,
renomeie objetos para atores e você já (quase)
entender Erlang.
Slide 21
Slide 21 text
Um pouco mais de mundo real:
A função de despacho
Slide 22
Slide 22 text
●
Alguém precisa decidir o que fazer com uma
mensagem....
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
●
A idéia de classe é acidental. Classes existem
para facilitar a vida de quem implementa a
linguagem de programação.
Slide 26
Slide 26 text
●
Um exemplo:
– Vamos imaginar uma aplicação gráfica com os
seguintes objetos:
●
Reta
●
Ponto
●
Segmento de reta
– Como modelar uma operação 'intersecção' entre
esses objetos ??
Slide 27
Slide 27 text
●
Até agora assumimos implicitamente que o
despacho só ocorre tomando em conta o
*tipo* do objeto receptor.
Slide 28
Slide 28 text
●
Precisamos de um truque: despacho duplo
Slide 29
Slide 29 text
●
Mas.... isso é feio né ?
●
OO funciona bem quando as mensagens
podem ser respondidas por um único objeto
(lembre-se da analogia célula/máquina)
●
Esse exemplo mostra um caso impossível de
manter o open-closed principle.
Slide 30
Slide 30 text
●
Despacho múltiplo (CLOS, circa 1990):
Slide 31
Slide 31 text
●
C# 4.0 (!)
Slide 32
Slide 32 text
●
Depois de toda essa conversa, vamos pensar
no javascript.
– Javascript é orientado a objeto?
Slide 33
Slide 33 text
●
Na verdade, pouco importa.
– A linguagem que você usa pode te dar um jeito
bacana de configurar a função de despacho.
– Quem manifesta OO é o programador, e não a
linguagem. Nada te impede de escrever COBOL
em Javascript ou Ruby.
Slide 34
Slide 34 text
●
As linguagens e técnicas que conhecemos
existem com o propósito de dar forma a essa
visão de OO que foi descrita.
●
Basicamente, design patterns são técnicas
para obedecer os princípios de OO diante de
certas famílias de problemas
Slide 35
Slide 35 text
●
Há cenários em que a OO tem dificuldade em
se adequar, como o exemplo dos objetos
geométricos.
●
O princípio que “um objeto desconhece
completamente o outro” não encaixa nesses
casos.