Paradigma da Programação Orientada a Objetos: Para que ela serve e qual é a sua importância

Introdução

A Programação Orientada a Objetos (POO) consolidou-se como um dos paradigmas estruturais mais influentes da engenharia de software ao organizar sistemas em "objetos" autônomos, por meio de “moldes” (ou classes) que unem estado interno e comportamento. Essa abordagem superou as limitações da programação procedural tradicional (estrutural), que lutava para gerenciar bases de código em expansão, e realçou ainda mais o uso de funções e procedimentos em um contexto ou escopo ainda mais específico em códigos: os chamados métodos. Ao encapsular dados e funções, esse paradigma se tornou essencial para lidar com a complexidade de softwares modernos, abrangendo desde sistemas operacionais até arquiteturas corporativas de rede, fundamentando-se nas escolhas arquitetônicas de diferentes linguagens contemporâneas e em práticas como os princípios SOLID, que será aprofundada um pouco mais para o final do Artigo.

Historicamente, as sementes de Orientação a Objeto surgiram entre as décadas de 1950 e 1960 com pesquisas no MIT e, logo após, com o desenvolvimento da linguagem Simula na Noruega, a primeira a introduzir formalmente conceitos como classes, herança e instanciação de objetos para modelar sistemas físicos. Contudo, o grande divisor de águas ocorreu na década de 1970, no Xerox PARC, com o trabalho de Alan Kay na criação do Smalltalk. Inspirado na biologia celular, Kay cunhou o termo "Programação Orientada a Objetos" e estabeleceu a primeira implementação pura do modelo, baseada na troca dinâmica de mensagens e no encapsulamento estrito.

A consolidação industrial da POO ocorreu a partir da década de 1980, primeiramente com o C++, que fundiu o controle de baixo nível da linguagem C com as estruturas de classes, popularizando o formato na indústria. Contudo, o domínio global foi estabelecido nos anos 1990 com o lançamento do Java, desenvolvido pela Sun Microsystems e a liderança técnica de James Gosling, que impulsionou irreversivelmente o paradigma no mercado corporativo e na internet com sua arquitetura de máquina virtual. Quase na mesma época, o Python também emergiu, oferecendo uma abordagem orientada a objetos orgânica e multiparadigma (suporte de mais de um estilo de programação), garantindo a adaptação e a sobrevivência do modelo computacional até os dias atuais.

O progresso de POO

A evolução histórica da Programação Orientada a Objetos é marcada por uma grande divergência filosófica e técnica entre a visão ontológica original e a implementação pragmática adotada pelo mercado corporativo. De um lado, Alan Kay idealizou o paradigma centrado na troca assíncrona de mensagens, na proteção impenetrável do estado interno e na resolução de chamadas em tempo de execução. Sob essa ótica, os objetos não deveriam expor seus dados sob nenhuma circunstância, mas atuar como entidades autônomas e reflexivas que reagem isoladamente às requisições recebidas.

Essa linhagem purista, refletida na arquitetura de linguagens como Smalltalk e Ruby, estrutura os sistemas de software como uma rede de microsserviços ou células biológicas microscópicas. A comunicação baseada puramente em mensagens garante um polimorfismo genuíno e propício à assincronia, onde o remetente não precisa conhecer previamente a classe estrutural do destinatário. Além disso, a falha na recepção de uma mensagem não resulta em um colapso imediato do sistema, permitindo o tratamento dinâmico de erros e a orquestração de comportamentos complexos através de níveis formidáveis de metaprogramação (técnica avançada de programação que permite que um programa manipule ou modifique seu próprio código ou o de outros programas em tempo de execução ou compilação).

Em contraste agudo, as linguagens derivadas da sintaxe do C, com destaque para C++ e Java, desviaram-se desse modelo celular para priorizar a eficiência de hardware e a segurança de tipos por meio de taxonomias de classes rígidas e despachos estáticos de funções associados a tabelas virtuais de memória. Embora essa abordagem estrutural seja criticada por gerar hierarquias engessadas (ilustradas pelo problema de ser obrigado a importar um "gorila" e sua "selva" apenas para utilizar uma "banana"), seus defensores argumentam que a perda da flexibilidade biológica original é amplamente compensada pela altíssima eficiência de processamento, pela previsibilidade durante manutenções de código e pelas abstrações robustas validadas em tempo de compilação, ainda que de certa forma esse pensamento ainda é utilizado nos pilares do paradigma e, especialmente, em algumas das boas práticas de SOLID

Após toda essa base teórica, partimos ao ponto-chave do artigo: os pilares da Programação Orientada e Objetos, para saber melhor e de forma mais lúdica a sua importância e para quais contextos ela serve e suas vertentes utilizadas como base para boas práticas

Os Pilares

A literatura canônica de engenharia de software consolida a Programação Orientada a Objetos em torno de quatro pilares indissociáveis: Abstração, Encapsulamento, Herança e Polimorfismo, como se pode ver alguns pequenos exemplos na próxima figura. Esses princípios atuam em conjunto para mitigar o acoplamento de código, promover a alta coesão interna e garantir que bases de software volumosas permaneçam testáveis, escaláveis e passíveis de manutenção ao longo do tempo, independentemente se a linguagem utilizada possui tipagem estática (como Java e C#) ou dinâmica (como Python e JavaScript).

A Abstração é o princípio raiz do design orientado a objetos. Filosoficamente, consiste na criação de modelos que oferecem uma compreensão "suficiente" para utilizar um sistema, ocultando a complexidade de sua mecânica interna. Foca-se no "o que" o objeto pode fazer, e não no "como" ele faz. O objetivo é criar interfaces finas e de fácil compreensão, enquanto a implementação detalhada permanece oculta. Em linguagens de tipagem estática, isso é frequentemente formalizado por Interfaces e Classes Abstratas impostas pelo compilador. Em linguagens dinâmicas, baseia-se fortemente em "duck typing" e coesão semântica.

Um exemplo é o uso de uma interface ou classe abstrata por diversas classes. Na interface de forma geométrica ou forma abstrata, tanto a classe círculo quanto a classe quadrado utilizam o método abstrato "calcularArea", contudo, como cada forma faz o cálculo e implementa o método de forma distinta, dessa forma, enquanto o círculo calcula o produto de pi pelo raio ao quadrado, o quadrado calcula pelo lado ao quadrado, por exemplo

Intimamente ligado à abstração, o Encapsulamento é o escudo que protege o estado interno de um objeto. Ao restringir o acesso direto aos dados e exigir que as alterações ocorram exclusivamente através de métodos públicos controlados (getters e setters), o encapsulamento garante que as regras de negócios não sejam violadas e mantém a consistência do objeto durante seu ciclo de vida. Linguagens como Java impõem essa proteção de forma rigorosa através de modificadores de acesso (private, protected). O Ruby aplica restrições absolutas por design, enquanto o Python adota uma abordagem baseada em convenções comunitárias, utilizando prefixos (_) para indicar membros privados.

Nesse exemplo ilustrativo, podemos ver que o acesso interno a classe como um todo é completamente restrito, inclusive atributos privados ou não acessíveis. Contudo, é possível por getters (getSaldo) e setters (depositar e sacar) alterar valores do atributo saldo. Isso é muito importante para manter a privacidade de determinadas funções e atributos que podem ser sensíveis a classes externas. Além disso, em casos como o citado de exemplo, como o valor é somente alterado pelos setters e não de forma bruta ou "na mão", é possível implementar por dentro do método regras de negócios exclusivas para o atributo (como, por exemplo, não poder fazer um depósito maior que x reais e sacar um valor maior que um saldo), algo que pode não parecer muito relevante quanto eles somente servem para alterar e coletar o valor, mas se tornam quando é necessário também uma alteração no domínio da classe

A Herança é a força motriz para a reutilização de código através de hierarquias de classes. Embora no nível básico seja ensinada como uma forma de modelar ontologias biológicas ou estruturais ("Cachorro é um Mamífero"), na engenharia profissional, seu foco deve ser o compartilhamento algorítmico pragmático e a facilitação do polimorfismo arquitetural. A herança só deve ser utilizada quando há um relacionamento irrefutável do tipo "é um" (is-a). Um uso estratégico comum é a refatoração tática, centralizando a lógica repetitiva (como autenticação ou tratamento de erros em requisições de rede) em uma classe base fundamental. Essa prática elimina a duplicação, permitindo que as classes filhas herdem comportamentos comuns e se concentrem exclusivamente na resolução de demandas específicas de seu próprio contexto.

Como é visto, os atributos marca, modelo, ano e os métodos ligar e frear fazem parte de um veículo, podendo ser carros, motos, caminhões, etc. Assim sendo, é possível essas subclasses herdarem a superclasse veículo e adicionar ou atualizar o que for necessário, se conectando bem com o conceito de abstração, pois isso vai da classe mais abstrata (veículos) a classes bem mais concretas (carro e moto)

O Polimorfismo consolida-se como o pilar estrutural mais dinâmico da Programação Orientada a Objetos, permitindo que instâncias de diferentes classes sejam manipuladas de forma padronizada através de uma interface comum. Sua principal vantagem arquitetural, profundamente alinhada aos preceitos de código limpo e design sólido, é a descentralização do controle de fluxo. Em vez de o sistema inspecionar manualmente os tipos de dados através de frágeis cadeias de if/else ou switch/case, ele adota o princípio "Diga, Não Pergunte" (Tell, Don't Ask). O controlador da aplicação apenas emite um comando genérico, transferindo para o próprio objeto a responsabilidade autônoma de executar o comportamento adequado à sua natureza estrutural. O ponto mais utilizado e conhecido do polimorfismo é a implementação de diversas formas de um método, em que o "falar" de um animal pode ser completamente diferente de um outro, como o latido de um cachorro, miado de um gato e um piado de um passarinho

Para viabilizar essa arquitetura flexível, o mecanismo manifesta-se em dois principais polimorfismos, sendo um o universal (uma mesma implementação funciona para múltiplos tipos) e o ad-hoc (casos específicos, como sobrecarga de métodos ou coerção de tipos). Ambos possuem 2 subtipos, sendo o paramétrico e inclusivo para o universal e o dinâmico e estatíco para o ad-hoc

O Polimorfismo Estático (Sobrecarga ou Overloading) é resolvido de formpilador, permitindo a declaração de múltiplos métodos homônimos em uma mesma classe, roteados através de suas assinaturas de parâmetros distintas, sendo um exemplo a sobrescrita de um método de uma classe pai por uma classe filha. O Polimorfismo Dinâmico (Sobrescrita ou Overriding), por sua vez, ocorre em tempo de execução através da amarração tardia e exige uma hierarquia de herança, onde a classe filha reescreve ativamente a lógica da classe pai para garantir que uma chamada genérica ative seu comportamento específico, sendo a interação comum de uma Lista ou Estrutura de Dados. Complementando o ecossistema, o Polimorfismo Paramétrico (Genéricos, amplamente aplicados na construção de repositórios e coleções no Java ou C#) permite a criação de estruturas tipadas e seguras cujos tipos exatos são definidos apenas na instanciação, promovendo a reutilização massiva sem duplicação algorítmica, utilizado em atributos genéricos como T (que significa que o atributo pode aceitar tanto texto, quanto números e entre outros). Por último, Polimorfismo Inclusivo (Subtipagem) é o modelo que um objeto pode ser tratado de forma formal como se fosse de outro tipo, contato que exista uma relação hieráquica de herança sobre eles, sendo semelhante ao polimorfismo dinâmico, permitindo, por exemplo que o sistema invoque um método de uma classe base (ex: veiculo.acelerar()), mas o comportamento executado seja o da classe derivada específica instanciada na memória (ex: Carro ou Moto).

Conteúdo Extra: SOLID

À medida que os sistemas orientados a objetos crescem em tamanho e complexidade, manter o código limpo, flexível e fácil de dar manutenção torna-se um grande desafio. Para mitigar problemas comuns de arquitetura (como código rígido que quebra facilmente ao ser alterado), o engenheiro de software Robert C. Martin introduziu, no início dos anos 2000, um conjunto de diretrizes de design. O acrônimo SOLID, cunhado mais tarde por Michael Feathers, agrupa cinco princípios fundamentais que se tornaram o padrão ouro na engenharia de software orientada a objetos:

S - Single Responsibility Principle (Princípio da Responsabilidade Única): Uma classe deve ter uma, e apenas uma, razão para mudar. Isso significa que cada classe deve ter apenas um trabalho ou responsabilidade. Por exemplo, uma classe que representa um usuário (User) não deve também ser responsável por salvar os dados desse usuário em um arquivo; essas devem ser responsabilidades de classes distintas.
O - Open/Closed Principle (Princípio do Aberto/Fechado): Entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação. Você deve ser capaz de adicionar novos comportamentos ou funcionalidades ao sistema sem alterar o código existente, geralmente utilizando interfaces e polimorfismo.
L - Liskov Substitution Principle (Princípio da Substituição de Liskov): Objetos em um programa devem ser substituíveis por instâncias de seus subtipos sem alterar a integridade ou a corretude desse programa. Se você tem uma classe base e uma classe filha, você deve poder usar a classe filha em qualquer lugar onde a classe base é esperada, sem causar erros. Uma violação clássica ocorre no problema do "Quadrado e Retângulo": se uma classe Quadrado herda de Retangulo, a alteração da largura de um quadrado modificará automaticamente sua altura. Se o sistema espera um comportamento de retângulo (onde largura e altura variam de forma independente), a substituição causará comportamentos inesperados e bugs. Para refatorar violações do LSP, a solução frequentemente envolve quebrar a herança incorreta e introduzir abstrações comuns (como uma interface FormaGeometrica implementada separadamente por ambos) ou favorecer a composição em vez da herança. Daí vem o Princípio de Refatoração
I - Interface Segregation Principle (Princípio da Segregação de Interfaces): Os clientes não devem ser forçados a depender de interfaces que não utilizam. Em vez de criar uma interface grande e monolítica que obriga as classes a implementarem métodos desnecessários, é preferível criar várias interfaces menores e mais específicas.
D - Dependency Inversion Principle (Princípio da Inversão de Dependência): Módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações. Além disso, as abstrações não devem depender de detalhes, mas os detalhes devem depender de abstrações. Esse princípio é frequentemente implementado usando técnicas como Injeção de Dependência para reduzir o acoplamento entre as classes.

Conclusão

A Programação Orientada a Objetos percorreu um longo caminho desde as suas origens no Simula 67 e no Smalltalk, ramificando-se em diversas implementações que atendem a diferentes necessidades da engenharia de software. Enquanto algumas linguagens mantêm uma abordagem mais dinâmica, outras, como C# e Java, adotaram estruturas mais estáticas, apresentando diferenças notáveis em suas implementações, como o uso nativo de propriedades e eventos no C# em contraste com os métodos getter e setter tradicionais e interfaces funcionais do Java. Além disso, o ecossistema continua a evoluir, como visto no JavaScript, que introduziu a sintaxe de classes do ES6 para atuar de forma mais limpa sobre sua herança baseada em protótipos.

Independentemente da linguagem escolhida, o domínio dos quatro pilares da POO e a aplicação rigorosa de padrões de design, como os princípios SOLID, são essenciais para a construção de sistemas robustos, escaláveis e de fácil manutenção. Embora novos paradigmas, como o Design Orientado a Dados (DOD), venham ganhando espaço em áreas que exigem o máximo de desempenho do hardware (como o desenvolvimento de jogos), a Programação Orientada a Objetos permanece como a base fundamental da engenharia de software moderna, capacitando desenvolvedores a modelar soluções complexas de forma lógica e organizada.