Programação orientada a objetos: conceitos e exemplos

A programação orientada a objetos, ou POO, organiza um programa em objetos que combinam estado e comportamento. O objetivo é construir componentes com responsabilidades compreensíveis e regras bem definidas. Criar classes, por si só, não garante um projeto organizado: é preciso decidir o que cada objeto sabe, o que faz e como colabora com os demais.

Este guia apresenta os conceitos por meio de um sistema fictício de empréstimos de uma biblioteca universitária. O exemplo permite acompanhar classes, objetos, encapsulamento e polimorfismo sem depender da sintaxe de uma linguagem específica. A videoaula ao final mostra uma aplicação prática em Java.

O que é um objeto na programação?

Um objeto possui identidade, estado e comportamento. A identidade distingue uma instância de outra, mesmo quando seus dados parecem iguais. O estado reúne informações relevantes naquele momento. O comportamento corresponde às operações pelas quais o objeto participa do programa.

No exemplo da biblioteca, dois exemplares do mesmo título podem ter códigos diferentes e situações distintas: um está disponível, outro está emprestado. O título não basta para identificar cada exemplar. O sistema precisa representar essa diferença para impedir que o mesmo item físico seja emprestado simultaneamente a duas pessoas.

Um objeto de software não precisa corresponder a algo físico. Um empréstimo, uma política de prazo ou um serviço de notificação também podem participar do modelo. A escolha depende do problema que o programa pretende resolver, e não de reproduzir todos os substantivos de uma descrição.

Classe e objeto: modelo e instância

Uma classe define uma estrutura de dados e operações para suas instâncias em linguagens baseadas em classes, como Java. O objeto é uma instância concreta criada durante a execução. A classe Exemplar pode definir código e situação; os objetos exemplarA e exemplarB armazenam valores próprios para esses atributos.

O construtor normalmente participa da criação e inicialização de uma instância, conforme as regras da linguagem. Uma inicialização válida pode exigir um código não vazio. Começar com dados coerentes reduz a quantidade de situações inválidas que o restante do sistema precisa tratar.

Nem toda linguagem orientada a objetos usa classes da mesma maneira. Linguagens com modelos baseados em protótipos mostram que “orientação a objetos” e “uso de classes” não são expressões perfeitamente equivalentes. Aqui, a explicação se concentra no modelo de classes usado no vídeo e na documentação Java indicada nas referências.

Encapsulamento: proteger regras, não apenas atributos

Encapsular significa definir uma fronteira de acesso ao estado e oferecer operações que mantenham as regras do componente. No sistema fictício, não deveria ser possível alterar livremente o status de um exemplar sem registrar o empréstimo correspondente. O problema é a consistência do modelo, não apenas a visibilidade de uma variável.

Uma regra que deve continuar verdadeira é chamada de invariante. Por exemplo: “um exemplar não pode ter dois empréstimos ativos ao mesmo tempo”. O método responsável por emprestar precisa verificar a situação atual e tratar uma tentativa incompatível, em vez de simplesmente sobrescrever um campo.

Criar um método de leitura e outro de escrita para cada atributo não resolve automaticamente o encapsulamento. Um método que aceita qualquer status pode expor o mesmo problema de um atributo público. Prefira operações com significado no domínio, como emprestar, devolver ou cancelar reserva, quando elas expressarem as regras necessárias.

Abstração: selecionar o que importa para o problema

A abstração destaca características relevantes e deixa de fora detalhes que não ajudam na tarefa atual. Para controlar empréstimos, pode ser necessário conhecer código, prazo e vínculo com o usuário. Cor da capa e posição de cada palavra na página provavelmente não fazem parte desse modelo.

Essa seleção não é permanente nem universal. Um sistema de conservação de acervo pode precisar de características físicas ignoradas pelo sistema de circulação. Um modelo adequado é aquele que atende aos objetivos e permite explicar suas decisões. Acrescentar atributos “para o caso de um dia precisar” aumenta o custo sem assegurar utilidade.

Abstração e encapsulamento se relacionam, mas não são sinônimos. A primeira ajuda a definir a visão do componente e suas responsabilidades. O segundo controla como essa visão é usada e como o estado é protegido pelas operações. Uma interface pequena pode expressar uma boa abstração e esconder uma implementação complexa.

Herança e composição: duas formas de relacionar componentes

A herança permite definir um tipo a partir de outro, com características e comportamentos herdados segundo as regras da linguagem. Ela faz sentido quando existe uma relação de substituição coerente. Reutilizar algumas linhas de código, sem essa relação, é uma motivação fraca para criar uma hierarquia.

Imagine que uma subclasse de um item emprestável proíba justamente a operação de empréstimo. Quem recebe o tipo mais geral pode esperar um comportamento que essa subclasse não oferece. Esse conflito indica que a hierarquia merece revisão: talvez o acervo precise distinguir itens consultáveis e itens que realmente podem circular.

Na composição, um objeto usa outros para realizar suas tarefas. Um serviço de empréstimos pode receber uma política de prazo e um notificador. Assim, alterações na comunicação por e-mail não precisam modificar a representação de cada exemplar. A composição permite variar colaboradores, mas também exige contratos claros entre eles.

Não há uma regra de que toda herança é ruim ou toda composição é melhor. Avalie estabilidade do contrato, necessidade de substituição e impacto das mudanças. Uma hierarquia curta e coerente pode ser adequada; uma rede de colaboradores sem responsabilidades definidas também pode ser difícil de manter.

Polimorfismo e interfaces com um exemplo

O polimorfismo permite tratar diferentes implementações por uma abstração comum. No exemplo, um serviço solicita “enviar aviso” a um notificador sem precisar decidir, naquele ponto, como cada canal realiza o envio. Um notificador por e-mail e outro do ambiente de testes podem atender ao mesmo contrato.

Uma interface, no contexto Java, expressa um contrato que tipos podem implementar. Ela ajuda a separar o que é esperado de como isso é realizado. Polimorfismo não exige que todas as implementações pertençam a uma longa cadeia de herança de classes; um contrato comum pode ser suficiente.

O exemplo de teste é útil porque evita enviar mensagens reais durante a verificação do programa. O teste pode conferir se o aviso foi solicitado para a pessoa e o prazo corretos. Ainda serão necessários testes apropriados da integração real, mas responsabilidades separadas facilitam identificar onde ocorre uma falha.

Como modelar o sistema passo a passo

Uma simulação manual ajuda: o serviço recebe o código BIB-042, verifica disponibilidade, cria o registro de empréstimo e atualiza a situação. Se uma etapa falhar, o programa precisa evitar um registro incompleto que contradiga o estado do exemplar. Em aplicações reais, persistência e concorrência exigem cuidados adicionais; objetos em memória não resolvem essas questões sozinhos.

Erros comuns ao aprender POO

• Criar uma classe enorme que concentra empréstimos, usuários, relatórios e mensagens.
• Usar herança apenas para evitar repetição, sem avaliar substituição de tipos.
• Expor todo o estado por métodos de escrita irrestritos.
• Confundir nome de classe com responsabilidade bem definida.
• Acrescentar padrões de projeto antes de existir um problema que justifique sua complexidade.

Um bom exercício é escrever, em uma frase, a responsabilidade de cada componente. Se a frase exige muitos “e”, considere se há tarefas independentes. Isso é um indício para examinar o modelo, não uma fórmula automática para fragmentar qualquer classe em várias outras.

Perguntas frequentes sobre programação orientada a objetos

POO substitui a programação procedural?

São formas de estruturar soluções que podem coexistir. Métodos contêm sequências de operações, e linguagens modernas frequentemente permitem vários estilos. Escolha uma organização que facilite compreender e modificar o problema, em vez de tratar um paradigma como garantia universal de qualidade.

Preciso decorar os quatro pilares?

Conhecer os nomes ajuda, mas demonstrar as decisões é mais importante. Explique qual regra o encapsulamento protege, por que uma abstração foi escolhida e como uma implementação pode substituir outra. Um modelo pequeno com justificativa vale mais que uma lista decorada sem aplicação.

Como continuar estudando?

Implemente o exemplo em uma linguagem, teste tentativas inválidas e compare duas versões do modelo. Consulte a documentação oficial e os materiais da área de Tecnologia. Ao comparar desempenho entre versões, defina medidas e condições, seguindo os cuidados de uma análise de estatística descritiva.

Vídeo para aprofundar