Questão de Programação — Programação Orientada a Objetos — Quadrix 2025
- Código
- qg595987
- Banca
- Quadrix
- Órgão
- CRA-SP
- Ano
- 2025
- Nível
- Superior
- Cargo
- Analista II - Desenvolvimento de Sistemas
- Apolimorfismo
- Bherança
- Cabstração
- Dencapsulamento
- Edelegação
GabaritoD — encapsulamento
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.
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.
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.
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.
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.
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