Pular para o conteúdo principal

Questão de Programação — Programação Orientada a Objetos — Quadrix 2025

ProgramaçãoProgramação Orientada a Objetos
Código
qg595987
Banca
Quadrix
Órgão
CRA-SP
Ano
2025
Nível
Superior
Cargo
Analista II - Desenvolvimento de Sistemas
Durante a revisão de código, um desenvolvedor sênior identificou que uma classe Fatura permite que outras classes modifiquem diretamente seu atributo status (ex: fatura.status = “PAGO”). O sênior recomendou que o atributo status seja tornado privado e que a modificação seja feita apenas através de um método público, como pagarFatura(), que conteria as regras de negócio.Com base nessa situação hipotética, assinale a opção que apresenta o princípio da programação orientada a objetos que fundamenta a recomendação do desenvolvedor sênior.
  1. Apolimorfismo
  2. Bherança
  3. Cabstração
  4. Dencapsulamento
  5. Edelegação
Revelar gabarito e comentário

GabaritoD — encapsulamento

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Encapsulamento em Programação Orientada a Objetos

Gabarito: letra D. A recomendação do desenvolvedor sênior — tornar o atributo status privado e exigir que a modificação ocorra apenas por meio de um método público como pagarFatura() — é a essência do encapsulamento, um dos quatro pilares da POO. O encapsulamento consiste em esconder os detalhes internos de um objeto (atributos e implementação) e restringir o acesso direto a eles, expondo apenas uma interface controlada por métodos públicos. É exatamente isso que o enunciado descreve: impedir que outras classes alterem status diretamente e forçar a passagem por um método que aplica as regras de negócio.

O encapsulamento é um dos pilares fundamentais da programação orientada a objetos, ao lado de abstração, herança e polimorfismo. Ele responde à pergunta: como proteger o estado interno de um objeto? A resposta prática é: declarando os atributos como private (ou protected, quando necessário) e fornecendo métodos públicos — os famosos getters e setters, ou métodos de negócio mais ricos, como pagarFatura() — para acessar e modificar esses atributos de forma controlada.

A importância do encapsulamento vai além da simples proteção de dados. Ele permite que a classe valide e aplique regras de negócio antes de alterar um atributo. No exemplo da Fatura, se o atributo status fosse público, qualquer classe poderia atribuir "PAGO" sem verificar se a fatura já foi emitida, se o valor foi pago, se há juros, etc. Com o encapsulamento, o método pagarFatura() pode conter toda essa lógica, garantindo a integridade do objeto e a consistência do sistema.

Além disso, o encapsulamento promove a manutenibilidade e a flexibilidade do código. Se, no futuro, a regra de negócio mudar (por exemplo, exigir que o pagamento seja aprovado por um supervisor), basta alterar o método pagarFatura() — nenhuma outra classe precisará ser modificada, pois todas dependem apenas da interface pública. Isso reduz o acoplamento entre classes e facilita a evolução do software.

Na prática, o encapsulamento é implementado por meio de modificadores de acesso (como private, public, protected em Java, C#, Python, etc.) e pela exposição de métodos públicos que controlam o acesso aos atributos. É uma técnica tão fundamental que é cobrada em praticamente toda prova de POO, seja em questões conceituais, seja em questões de análise de código.

A pegadinha desta questão está em distinguir o encapsulamento dos demais pilares: abstração (focar no que é essencial, ignorando detalhes irrelevantes), herança (reutilizar código entre classes por relação "é-um") e polimorfismo (permitir que objetos de classes diferentes respondam à mesma mensagem de formas diferentes). O enunciado não fala de hierarquia de classes, nem de múltiplas formas de um método, nem de modelagem conceitual — fala especificamente de proteger o atributo e controlar o acesso por métodos, que é a definição clássica de encapsulamento.

Guarde essa fronteira: encapsulamento = esconder dados + expor métodos controlados. É exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O polimorfismo é a capacidade de um objeto assumir várias formas, ou seja, de métodos com o mesmo nome se comportarem de maneiras diferentes em classes distintas (sobrescrita/override) ou de métodos com o mesmo nome terem assinaturas diferentes (sobrecarga/overload). Nada no enunciado sugere múltiplas implementações ou comportamentos variados — a recomendação é apenas sobre restringir o acesso a um atributo. Portanto, não é o princípio que fundamenta a recomendação.

Alternativa B — ❌ Incorreta

A herança é o mecanismo pelo qual uma classe (subclasse) herda atributos e métodos de outra (superclasse), estabelecendo uma relação "é-um". O enunciado não menciona hierarquia de classes, nem reutilização de código entre classes pai e filha. A recomendação do sênior é sobre encapsulamento, não sobre herança.

Alternativa C — ❌ Incorreta

A abstração é o processo de modelar objetos do mundo real, focando nas características essenciais e ignorando as irrelevantes para o contexto. Embora a POO seja baseada em abstração, a recomendação específica de tornar o atributo privado e usar métodos públicos é uma medida de encapsulamento, não de abstração. A abstração está mais relacionada à modelagem conceitual (o que a classe representa), enquanto o encapsulamento trata da proteção dos dados.

Alternativa D — ✅ Correta ⟵ GABARITO

O encapsulamento é exatamente o princípio que fundamenta a recomendação: esconder os atributos (tornando-os private) e fornecer métodos públicos para acessá-los e modificá-los de forma controlada. O enunciado descreve a situação clássica de violação do encapsulamento (acesso direto ao atributo status) e a correção recomendada (método pagarFatura() com regras de negócio). É a definição literal do pilar.

Alternativa E — ❌ Incorreta

A delegação é um padrão de projeto em que um objeto delega a execução de uma tarefa a outro objeto, em vez de implementá-la diretamente. Não tem relação com a proteção de atributos ou com o controle de acesso por métodos. A recomendação do sênior não envolve delegar responsabilidades a outros objetos, mas sim encapsular o estado interno da própria classe.

Gabarito: letra D — o princípio que fundamenta a recomendação é o encapsulamento.

Link permanente: /questoes/qg595987