1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
# Eu tenho certeza que você, um sênior, não sabe o que é orientação à objetos
Sabe esse paradigma que aprendemos na faculdade? Os vários macetes, os
famigerados "Padrões de Projeto", o `sujeito.verbo(objeto)` e merdas assim?
Pois é, tá errado. Pelo menos de acordo com Alan Kay, porque Alan Kay não quis
dizer nada disso.
O negócio é que existem duas "escolas" de orientação à objetos. Uma que veio do
Alan Kay originalmente, e a outra que veio do Simula e que foi mais ou menos
raptado pelo Bjarne Strousturp, o criador do C++, e que veio a ser base do Java
e outras linguagens ditas "orientadas à objetos". Então aqui vou tentar ensinar
sobre o que o Alan Kay realmente quis dizer com orientação à objetos.
Antes eu quero que você saiba que o _Alan Kay não quis se focar nos objetos._
Ele até chegou a pedir desculpas por chamar isso de "Orientação a Objetos"
porque isso confundiu muita gente, porém dá pra explicar a orientação a objetos
com um padrão que você já deve ter usado a bastante tempo. Na verdade, se você
quer um TL;DR disso tudo, você pode resumir o que Alan Kay quis dizer à
"Injeção de Dependência embebido com mijo de Chuck Norris", e até a linguagem
que é realmente "Orientada à Objetos", o Smalltalk, tem seus pontos parecidos
com os da programação funcional. Irei usar um pseudo-código parecido com Java
para demonstrar.
Vejamos esse código aqui:
shape.getDimensions().getX()
Isso seria um código bem comum de ver em orientação a objetos, mas qual é a
interpretação que o Alan Kay teria sobre esse trecho?
O `shape` é um objeto e, como objeto, ele recebe e responde à mensagens, no
caso, shape recebeu a mensagem `getDimensions` sem parâmetros. `shape`
reconhece essa mensagem e dessa mensagem responde com um outro objeto. Então
enviamos `getX` sem parâmetros, e esse objeto pode ou não responder a essa
mensagem. O Alan Kay estava se focando nesse modelo de envio de mensagens e não
no modelo atual de classes. Inclusive quando Alan Kay falou de hierarquias ele
não tava falando de "extensão" de classes como vemos em Java e sim que uma
classe `Foo` responde as mesmas mensagens da classe `Base`.
Em outras palavras: **A CLASSE NÃO IMPORTA, O QUE IMPORTA É A INTERFACE!** O
que importa é se o `shape` reconhece `getDimensions`, inclusive tem um nome pra
isso, `Duck Typing`: se anda igual pato e quacka igual um pato, é um pato. A
classe, nessa visão, é só uma forma de construir objetos.
Isso torna umas coisas um pouco mais interessantes. Vejamos esse trecho
de código.
fn foo(thing) {
thing.isTrue(() -> {
doThing(thing)
})
}
O que `thing` é? Não sei, só sei que `foo` precisa que `thing` reconheça
`isTrue` com um parâmetro de lambda qualquer coisa que o `doThing` reconheça.
Isso torna o `foo` extremamente reaproveitável e é com essa parte que o Alan
Kay quis dizer com "reaproveitamento de código", e agora você entende o porquê
que muitos javeiros adotaram o padrão de fazer getter e setter pra tudo, porque
isso faz uma função depender de uma interface ao invés de uma implementação e
isso faz a função ficar mais reaproveitável (mas vamos ser sinceros, 99% dos
javeiros nem sabem disso, eles só fazem isso porque disseram que sim pra eles,
e nem mesmo Alan Kay gosta dos getters and setters porque as mensagens eram pra
*mandar* no objeto e não *pedir* ao objeto).
E perceba que eu usei lambda ao invés de ser algo mais procedural, como
`if`/`else`. Isso é porque a orientação a objetos realmente preza em tornar
todo código o mais reaproveitável possível e, ao usar `if`s, como o Java faria,
você torna o seu código um pouco mais rígido ao depender de uma implementação
de uma boolean. OOP do Alan Kay preza tanto por isso que esse mesmo exemplo
ficaria assim em Smalltalk (pelo menos, "aproximadamente" Smalltalk):
foo: object [
object ifTrue: [
self doThing: object
]
]
Não existe `if`/`else` em Smalltalk. E booleans não são tipos primitivos e sim
objetos. Integer, Strings, tudo é um objeto legítimo, com a sua lista de
mensagens que eles devem responder, e é aqui que a "Injeção de Dependência com
mijo de Chuck Norris" se apresenta. E de certa forma, é como nossos servidores
HTTP funcionam. Você não precisa saber se o servidor é feito em Java, C#, PHP,
feito com Spring Boot, Laravel ou algum outro framework. Você só precisa saber
se o servidor responde por um `POST /foo/bar`.
Isso é orientação à objetos. O resto é só putaria tirada da bunda do
Strousturp.
|
