adicionado tutoriais/orientação-a-objetos.mdHEADmaster

2 files changed, 89 insertions, 0 deletions

diff --git a/tutoriais/orientacao-a-objetos.md b/tutoriais/orientacao-a-objetos.md
new file mode 100644
index 0000000..b5121c0
--- /dev/null
+++ b/tutoriais/orientacao-a-objetos.md
@@ -0,0 +1,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.
diff --git a/tutoriais/posts.csv b/tutoriais/posts.csv
index ab5541f..8a86ba7 100644
--- a/tutoriais/posts.csv
+++ b/tutoriais/posts.csv
@@ -1 +1,2 @@
+Eu tenho certeza que você, um sênior, não sabe o que é orientação à objetos|orientacao-a-objetos.html|Mon, 15 Jun 2026 18:20:28 -0300
 Como dev, como você dev pensar?|makefiles.html|Mon, 15 Jun 2026 11:59:51 -0300