summaryrefslogtreecommitdiff
path: root/tutoriais/orientacao-a-objetos.md
diff options
context:
space:
mode:
Diffstat (limited to 'tutoriais/orientacao-a-objetos.md')
-rw-r--r--tutoriais/orientacao-a-objetos.md88
1 files changed, 0 insertions, 88 deletions
diff --git a/tutoriais/orientacao-a-objetos.md b/tutoriais/orientacao-a-objetos.md
deleted file mode 100644
index b5121c0..0000000
--- a/tutoriais/orientacao-a-objetos.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# 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.