POO não é uma Partícula Fundamental da Computação
26/11/2012
Esta é a tradução de OOP Isn't a Fundamental Particle of Computing
A maior mudança na programação ao longo dos últimos 25 anos é que hoje você pode manipular um conjunto de úteis e flexíveis tipos de dados que a 25 anos atrás você mesmo gastaria uma enorme quantidade de tempo construíndo esses tipos de dados.
C e Pascal - as linguagens padrão da época - providas de alguns tipos orientados à máquina: números, ponteiros, arrays, a ilusão de strings e uma maneira de amarrar vários valores juntos em um registro ou estrutura. A ênfase era sobre o uso desses rudimentos como trampolins para projetar tipos mais interessantes, tais como pilhas, árvores, listas ligadas, tabelas hash e arrays redimensionáveis.
Em Perl ou Python ou Erlang, eu não penso sobre essas coisas. Eu uso listas, strings, arrays, sem preocupação com o número de elementos que contenham ou de onde a memória vem. Para quase tudo o que eu usar dicionários, novamente não vou gastar tempo me preocupando sobre o tamanho ou detalhes de como colisões de hashes são tratadas.
Eu ainda preciso de novos tipos de dados, mas é mais um reaproveitamento do que já existe do que a elaboração de uma solução personalizada. Um vetor de dimensão arbitrária é um array. Uma cor RGB é uma tupla de três elementos. Um polinômio é ou uma tupla (onde cada valor é o coeficiente e o índice é o grau) ou uma lista de tuplas
{coeficiente, grau}
. É surpreendente como arrays, tuplas, listas e dicionários eliminaram a maior parte do trabalho pesado dos cursos de estrutura de dados que fiz na faculdade. O foco na implementação de uma árvore binária balanceada é sobre como árvores binárias balanceadas trabalham e não sobre o sofrimento através da manipulação de um emaranhado de ponteiros.
Pensando em como organizar blocos pré-fabricados de construção em algo novo é uma mudança radical ao que pode parecer à primeira vista. Como esses blocos de construção se vêm à existência já não é a principal preocupação. Em muitos cursos de programação e tutoriais, tudo vai muito bem até que há um choque repentino na velocidade do vocabulário: objetos e construtores e classes base abstratas e métodos privados. Então, na próxima missão da tupla de três elementos simples que representa uma cor RGB é substituída por uma classe com getters e setters e construtores múltiplos e - o mais crítico - muito mais código.
Este é o lugar onde alguém precisa desesperadamente intervir e explicar por que isso é uma má idéia e o fim da diversão, mas isso raramente acontece.
Não é que POO seja ruim ou até mesmo falhe. É que programação orientada a objetos não é uma partícula fundamental da computação que algumas pessoas querem que ela seja. Quando cegamente aplicada a problemas abaixo de um limite de complexidade arbitrária, POO pode ser detalhada e artificial, mas muitas vezes há uma insistência estética em objetos para tudo até o fim. Isso é muito ruim, porque faz com que seja mais difícil de identificar os casos em que um estilo orientado a objeto realmente resulta em uma simplicidade total e na facilidade de compreensão.