Programação · FUNDATEC · 2026 | Questão sqc-qg685508

ProgramaçãoProgramação Orientada a Objetos

Código: qg685508
Banca: FUNDATEC
Órgão: IFC-SC
Ano: 2026
Nível: Superior

Cargo: Professor EBTT - Computação

Considere uma linguagem orientada a objetos com despacho dinâmico para métodos sobrescritos. Uma empresa de RH desenvolve um sistema de folha de pagamento que modela funcionários por meio de uma classe base Funcionario, da qual derivam FuncionarioCLT e FuncionarioPJ, cada uma sobrepondo (overriding) o método calcularSalario() com regras de cálculo distintas. Um módulo de relatórios recebe uma lista do tipo Funcionario e invoca calcularSalario() em cada elemento sem conhecer o tipo concreto de cada objeto. Quando a empresa contrata um novo tipo de vínculo e cria a classe FuncionarioSocio — também derivando de Funcionario e sobrepondo calcularSalario() — o módulo de relatórios não precisa de nenhuma alteração. Nesse contexto, assinale a alternativa que identifica corretamente os mecanismos de orientação a objetos que tornam esse comportamento possível e explica por que o módulo não precisa ser modificado.

AO encapsulamento permite às subclasses acessar diretamente os atributos privados da superclasse; calcularSalario() pode ser invocado sem conhecimento do tipo concreto, e novas subclasses dispensam alterações no módulo, pois os campos privados são acessíveis por herança
BA herança estabelece relação de subtipo que permite a referências do tipo Funcionario apontarem para qualquer instância concreta; o polimorfismo por ligação dinâmica resolve calcularSalario() em tempo de execução para a implementação correta — novas subclasses de Funcionario são automaticamente compatíveis com o módulo.
CA sobrecarga (overloading) de calcularSalario() nas subclasses permite ao compilador selecionar a implementação correta em tempo de compilação, com base nos tipos declarados; por ser estática, essa seleção não é afetada pela adição de novos tipos.
DO encapsulamento impede que subclasses redefinam calcularSalario() de forma incompatível com a superclasse, garantindo que o módulo nunca receba objetos cujo comportamento contradiga o contrato da classe base.
EO polimorfismo é implementado via sobrecarga (overloading): versões distintas de calcularSalario() são definidas na própria classe Funcionario e selecionadas em tempo de compilação pelos argumentos; herança não é necessária.

Revelar gabarito e comentário

GabaritoB — A herança estabelece relação de subtipo que permite a referências do tipo `Funcionario` apontarem para qualquer instância concreta; o polimorfismo por ligação dinâmica resolve `calcularSalario()` em tempo de execução para a implementação correta — novas subclasses de `Funcionario` são automaticamente compatíveis com o módulo.

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”.

Mecanismos de Orientação a Objetos: Herança e Polimorfismo

Gabarito: letra B. O comportamento descrito é possível graças à combinação de herança (relação de subtipo) e polimorfismo por ligação dinâmica (dynamic dispatch). A lista declarada como Funcionario aceita objetos de qualquer subclasse (herança) e, ao invocar calcularSalario(), o sistema resolve em tempo de execução qual implementação concreta executar (polimorfismo). Novas subclasses, como FuncionarioSocio, automaticamente se encaixam no módulo de relatórios por herdarem de Funcionario e sobrescreverem o método, sem necessidade de alteração no código cliente.

Mecanismo	Descrição	Papel no cenário
Herança	Relação de subtipo: `FuncionarioSocio` é um `Funcionario`	Permite que referências do tipo `Funcionario` apontem para objetos de qualquer subclasse
Polimorfismo (ligação dinâmica)	Resolução do método `calcularSalario()` em tempo de execução	Garante que a implementação correta (da subclasse concreta) seja executada
Extensibilidade	Novas subclasses herdam automaticamente a compatibilidade com o módulo	O módulo de relatórios não precisa ser alterado ao adicionar `FuncionarioSocio`

Alternativa A — ❌ Incorreta

Afirma que o encapsulamento permite acesso direto a atributos privados por subclasses, o que é falso — encapsulamento oculta atributos e o acesso a privados não é permitido por herança (a menos que haja modificadores como protected). Além disso, o que viabiliza a extensibilidade é o polimorfismo, não o encapsulamento.

Alternativa B — ✅ Correta ⟵ GABARITO

Descreve corretamente a herança como relação de subtipo (referências do tipo base apontam para objetos concretos) e o polimorfismo por ligação dinâmica, que resolve o método correto em tempo de execução. Isso torna o módulo extensível sem modificações.

Alternativa C — ❌ Incorreta

Confunde sobrescrita (overriding) com sobrecarga (overloading). A questão trata de métodos sobrescritos, cuja seleção é dinâmica (runtime). Sobrecarga é estática (compile-time) e exige assinaturas diferentes; não se aplica aqui.

Alternativa D — ❌ Incorreta

O encapsulamento não impede que subclasses redefinam métodos. Na verdade, a sobrescrita é permitida justamente para que subclasses alterem o comportamento herdado. O que garante a compatibilidade é o contrato da classe base, mas o mecanismo que permite a substituição é a herança e o polimorfismo.

Alternativa E — ❌ Incorreta

Afirma que o polimorfismo é realizado por sobrecarga, o que é falso. A sobrecarga é estática e não permitiria adicionar novas implementações sem modificar a classe base. Além disso, a herança é essencial para que as subclasses sobrescrevam o método.

NÃO CAIA NESSA!

A banca explora a clássica confusão entre overriding (sobrescrita, dinâmico) e overloading (sobrecarga, estático). Nas alternativas C e E, o termo "sobrecarga" é usado para tentar atrair quem não domina a diferença. Lembre-se: overriding = ligação tardia; overloading = ligação precoce.

Gabarito: letra B

Link permanente: /questoes/qg685508