Guru SP 2015 - OOP Hipster

Guru SP 2015 - OOP Hipster

4569aec00cb223b3fbf484f9e7ba1256?s=128

Renan Ranelli

March 02, 2015
Tweet

Transcript

  1. 1.

    OOP Hipster – Conceitos de OO fora do mainstream que

    todo programador deveria entender Renan Ranelli, 02/2015
  2. 2.

    • 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.
  3. 5.

    • 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.
  4. 6.

    • 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.
  5. 10.

    • 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
  6. 11.

    • 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.
  7. 12.

    • 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.
  8. 16.

    • 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
  9. 17.

    • 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
  10. 18.
  11. 19.

    • 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 ;)
  12. 20.

    • Bonus – Se você grokar a idéia de mensagens

    e objetos, renomeie objetos para atores e você já (quase) entender Erlang.
  13. 23.
  14. 24.
  15. 25.

    • A idéia de classe é acidental. Classes existem para

    facilitar a vida de quem implementa a linguagem de programação.
  16. 26.

    • 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 ??
  17. 27.

    • Até agora assumimos implicitamente que o despacho só ocorre

    tomando em conta o *tipo* do objeto receptor.
  18. 29.

    • 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.
  19. 32.
  20. 33.

    • 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.
  21. 34.

    • 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
  22. 35.

    • 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.
  23. 36.
  24. 38.