De Simula e Smalltalk às classes e protótipos modernos: objetos, mensagens, encapsulamento, polimorfismo e limites da herança.
A programação orientada a objetos (POO) é hoje tão familiar que é fácil esquecer a sua evolução histórica. Classes, objetos, métodos, herança, interfaces e polimorfismo não surgiram todos ao mesmo tempo nem como uma receita universal.
A orientação a objetos nasceu de uma pergunta prática: como representar entidades com estado, comportamento e interações com outras entidades? De Simula a Smalltalk, e depois C++, Java, Python e JavaScript, as respostas mudaram profundamente.
As linguagens de alto nível das décadas de 1950 e 1960 trouxeram funções, procedimentos, estruturas de dados e módulos. À medida que os sistemas cresciam, alterar dados manipulados por funções dispersas tornava-se dispendioso. Uma das respostas mais influentes surgiu na simulação.
Na década de 1960, os informáticos noruegueses Ole-Johan Dahl e Kristen Nygaard desenvolveram linguagens de simulação. Com Simula 67, introduziram mecanismos fundamentais: classes, objetos, herança e métodos virtuais. Uma classe descreve uma categoria; um objeto representa uma instância concreta.
No modelo clássico, uma classe define estrutura e comportamentos comuns e um objeto é uma instância com estado próprio. O modelo é central em C++, Java e C#, mas não é universal: existem sistemas baseados em protótipos.
No final da década de 1960 e início da de 1970, Alan Kay desenvolveu outra visão, aprofundada na nossa biografia de Alan Kay: o essencial eram objetos autónomos que trocam mensagens, e não hierarquias de classes.
No Xerox PARC, Alan Kay, Dan Ingalls, Adele Goldberg e outros desenvolveram Smalltalk. Números, coleções e classes participam no modelo de objetos e a interação centra-se nas mensagens. O ambiente interativo influenciou profundamente a computação pessoal e os IDE.
Um objeto combina normalmente estado, comportamento e identidade. Duas contas bancárias podem ter o mesmo saldo sem serem a mesma conta. Em alguns domínios a identidade é importante; noutros, valores imutáveis e funções são mais adequados. A POO é uma ferramenta, não uma obrigação universal.
O encapsulamento reúne estado e operações e limita o acesso aos detalhes internos. O seu objetivo é reduzir dependências e permitir que uma abstração mude sem quebrar os seus utilizadores.
A abstração mostra o que um componente sabe fazer sem expor a implementação. A POO não inventou a abstração, mas popularizou uma forma centrada em entidades que combinam estado e comportamento.
A herança permite a uma classe adquirir e especializar características de outra. Pode reutilizar código, mas também cria acoplamento e hierarquias rígidas. Hoje é considerada uma ferramenta entre várias.
O polimorfismo permite ao mesmo código trabalhar com objetos diferentes através de um comportamento comum. Pode basear-se em herança, interfaces, protocolos, duck typing ou mecanismos genéricos. A ideia central é programar para um contrato e não para uma implementação concreta.
A partir de 1979, Bjarne Stroustrup combinou ideias de Simula com a eficiência de C. O projeto tornou-se C++, que difundiu a POO na indústria sem abandonar outros paradigmas.
Objective-C, criado por Brad Cox e Tom Love, seguiu outro caminho: uma camada dinâmica sobre C inspirada nas mensagens de Smalltalk. Tornou-se importante na NeXT e na Apple antes da ascensão de Swift.
Na década de 1990, interfaces gráficas, design patterns e UML ajudaram a tornar a POO dominante. Chegou a ser apresentada como uma forma geral de conceber qualquer sistema, produzindo práticas duradouras, mas também excessos.
Java surgiu em 1995 com classes, garbage collection e interfaces. A nossa história de Java e a biografia de James Gosling aprofundam esta evolução.
C# adotou depois ideias familiares no .NET e evoluiu com generics, lambdas, LINQ, records e pattern matching. Mesmo linguagens fortemente associadas à POO tornaram-se multiparadigma.
Python suporta classes e polimorfismo sem os impor em todo o código. O duck typing privilegia frequentemente os comportamentos disponíveis em vez de uma hierarquia precisa.
JavaScript, criado por Brendan Eich, baseia-se historicamente em protótipos. A sintaxe moderna class continua assente nesse mecanismo.
Com a experiência, difundiu-se a recomendação preferir composição a herança. A composição reduz frequentemente o acoplamento e facilita a substituição de componentes. Não torna a herança inútil, mas evita transformar toda a reutilização numa árvore de classes.
As interfaces separam aquilo de que um componente necessita da implementação concreta. Esta ideia sustenta a injeção de dependências e vários princípios SOLID.
SOLID são heurísticas, não leis. Uma aplicação mecânica pode multiplicar classes, interfaces e camadas sem benefício. Uma abstração é útil quando representa uma verdadeira fronteira de responsabilidade ou variação.
Em 1994, Design Patterns popularizou padrões como Factory, Observer, Strategy, Decorator e Adapter. O seu principal valor é fornecer um vocabulário partilhado, não receitas obrigatórias.
UML unificou vários métodos de modelação e os diagramas de classes ficaram fortemente associados à POO. Patterns e diagramas ajudam a raciocinar, mas não substituem um desenho adequado ao problema.
Encapsulamento, interfaces e injeção de dependências podem facilitar testes através de fakes, stubs ou mocks. Mas fragmentar uma arquitetura apenas para facilitar mocking pode piorá-la. Mais abstrações não significam automaticamente melhor conceção.
Com o domínio da POO tornaram-se visíveis limitações: hierarquias profundas e frágeis, estado mutável partilhado, objetos demasiado interligados e arquiteturas “enterprise” carregadas de camadas e factories.
A programação funcional voltou a destacar funções puras e dados imutáveis. Hoje Java, C#, C++, Python e JavaScript combinam abordagens. A oposição «objetos contra funcional» é, por isso, cada vez menos útil.
Interfaces gráficas e jogos continuam a adaptar-se bem a entidades com estado e identidade, mas motores modernos também usam Entity Component System (ECS), favorecendo composição e separação dos dados.
Nos sistemas distribuídos, o modelo de atores organiza entidades que recebem mensagens e mantêm o próprio estado. Não é POO clássica, mas recorda a importância que Alan Kay atribuía às mensagens e ao isolamento.
Após décadas, encapsulamento, polimorfismo, composição, identidade e estado continuam a ser ideias particularmente duradouras. A grande hierarquia de classes, pelo contrário, perdeu influência.
Smalltalk, C++, Java, Python e JavaScript mostram que a POO é melhor entendida como uma família de modelos de programação do que como uma lista absoluta de requisitos.
Uma enorme quantidade de software e frameworks utiliza classes e objetos. Compreender encapsulamento, responsabilidades, contratos e polimorfismo continua útil. A maturidade consiste menos em «usar objetos em todo o lado» do que em escolher a representação adequada ao problema.
A POO nasce progressivamente com Simula, transforma-se com Smalltalk e Alan Kay, difunde-se industrialmente com C++ e torna-se dominante com Java. Python e JavaScript mostram modelos mais dinâmicos e multiparadigma.
A experiência corrigiu excessos: a herança deixou de ser a resposta natural a toda a reutilização, enquanto composição, interfaces, imutabilidade e funções ganharam importância.
A lição mais duradoura não é «tudo deve ser uma classe», mas agrupar responsabilidades coerentes, esconder detalhes desnecessários e permitir que os componentes colaborem sem depender excessivamente das implementações internas.
É uma família de abordagens que organiza software em torno de objetos com estado, identidade e comportamento, que colaboram através de métodos, mensagens ou interfaces.
Não existe um único inventor. Dahl e Nygaard introduziram mecanismos fundamentais em Simula; Alan Kay e a equipa Smalltalk desenvolveram depois uma visão centrada em mensagens.
Uma classe descreve estrutura e comportamentos comuns; um objeto é uma instância particular com estado próprio. Os sistemas baseados em protótipos funcionam de forma diferente.
Encapsulamento, abstração, herança e polimorfismo; na prática moderna, também composição, interfaces e gestão de dependências.
Não. Muitos sistemas preferem composição ou interfaces.
Sim, mas historicamente através de protótipos. A sintaxe class moderna continua a basear-se neles.
Sim, mas é multiparadigma e não obriga a organizar tudo em classes.
Não. Continua muito utilizada, embora já não seja considerada uma solução universal.
Muitas vezes, a composição produz componentes mais flexíveis e menos acoplados. A herança continua pertinente quando existe uma verdadeira especialização.
Porque encapsulamento, responsabilidades, contratos e polimorfismo continuam a ajudar a gerir a complexidade em arquiteturas multiparadigma.
Coleção
10 / 26
Como Bjarne Stroustrup fez C with Classes evoluir para C++, uma linguagem que concilia abstração, compatibilidade e controlo dos recursos.
Como Brendan Eich criou o primeiro JavaScript na Netscape e contribuiu para a sua evolução até se tornar a linguagem normalizada da Web.
Como James Gosling e a equipa Green da Sun conceberam Java: de Oak às máquinas virtuais e à promessa de portabilidade.