Armadilhas da programação orientada a objetos (2009) [pdf]
A programação orientada a objetos é examinada tanto como modelo conceitual quanto como troca de desempenho, e muitos argumentam que sua ênfase em identidade, estado mutável e herança muitas vezes adiciona complexidade sem benefícios claros em comparação com designs mais simples orientados a dados ou funcionais. Os comentaristas contrastam a visão original de Alan Kay, baseada em envio de mensagens, com a forma como OO mainstream (por exemplo, Java, C++) é praticada hoje, destacando problemas como grafos de objetos hostis ao cache, hierarquias de herança frágeis e o uso excessivo da ideia de que “tudo é um objeto”. Um tema recorrente é que nenhum paradigma único basta: sistemas eficazes misturam objetos, funções e modelos relacionais ou baseados em conjuntos, usando OO de forma seletiva onde estado encapsulado e comportamento polimórfico realmente ajudam, como em partes de código de UI.
O que OO “realmente é”
- Vários comentários argumentam que a definição da Wikipedia de “dados + métodos juntos” é enganosa.
- Uma corrente diz que a essência é identidade mais estado mutável: dois objetos podem ser “o mesmo” apesar de terem campos diferentes.
- Outra corrente enfatiza envio de mensagens + despacho dinâmico: objetos diferentes respondem de maneiras diferentes à mesma mensagem; mutabilidade e identidade são comuns, mas não essenciais.
- Ambas as visões concordam que o layout de memória é incidental, não definidor.
OO vs. outros paradigmas (identidade, conjuntos, relações)
- Um tema recorrente: OO incentiva “identidade intencional” (você inventa objetos/serviços e empurra dados/comportamento para dentro deles), o que pode inflar a complexidade do sistema.
- Em contraste, abordagens relacionais/lógicas enfatizam “identidade extensional” (entidades são definidas por valores/tuplas; a identidade emerge dos atributos).
- Alguns observam que muitos desenvolvedores estão tão imersos em OO que o veem como natural, e então envolvem de forma desajeitada sistemas relacionais/funcionais/lógicos em abstrações OO.
Herança, composição, interfaces
- Forte crítica à herança de classes como ferramenta primária de design; composição, interfaces/traits/typeclasses e delegação são frequentemente preferidas.
- Outros defendem a herança como um mecanismo poderoso e conveniente para extensibilidade e personalização de UI, especialmente quando cuidadosamente restringida (classes/métodos finais, pontos claros de extensão).
- Debate sobre se delegação + genéricos igualam a expressividade e a ergonomia da herança; concorda-se que o mau uso da herança facilmente leva a projetos frágeis.
OO em GUIs vs. backends
- Muitos acham que OO se encaixa bem em toolkits tradicionais de GUI (widgets com estado e comportamento, estrutura hierárquica).
- Frameworks de UI modernos (React, Elm, Compose, SwiftUI) tendem a estilos declarativos/funcionais ou reativos, embora críticos argumentem que eles ainda dependem de estado oculto, parecido com OO, por baixo.
- Discussão sobre hooks do React: eles parecem funcionais na superfície, mas quebram regras de FP pura e dependem de semânticas incomuns.
Desempenho e design orientado a dados
- Os slides são vistos como mostrando que grafos de objetos centrados em OO prejudicam a localidade de cache e o prefetching em comparação com layouts orientados a dados (por exemplo, arrays/vetores).
- Alguns generalizam: modularidade e abstração muitas vezes trocam com desempenho bruto; o design orientado a dados reage contra isso em código crítico de performance.
Pragmatismo e uso multiparadigma
- Vários comentaristas defendem a prática multiparadigma: OO para algumas partes, FP/relacional/lógico em outras.
- Posições extremas (“tudo é um objeto”, “tudo é imutável”) são vistas como contraproducentes; o problema deve ditar o paradigma.