Slide 1

Slide 1 text

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.

Slide 8

Slide 8 text

Mensagens, Objetos e Encapsulamento

Slide 9

Slide 9 text

Objeto 1 Objeto 2 mensagem(payload) possível resposta

Slide 10

Slide 10 text

● 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.

Slide 36

Slide 36 text

Dúvidas?

Slide 37

Slide 37 text

@rranelli /rranelli Blog: http://milhouseonsoftware.com

Slide 38

Slide 38 text

Obrigado!