Questão de Engenharia de Software — Orientação a Objetos — FGV 2025
Engenharia de Software›Orientação a Objetos
Código
fg104560
Banca
FGV
Órgão
AL-AM
Ano
2025
Nível
Superior
Cargo
Analista Legislativo - Analista de Sistema
O Analista de Sistemas está revisando um código que trata de licitações. Existe uma classe base Licitacao com um método iniciar(). Uma subclasse LicitacaoPresencial sobrescreve o método iniciar() com sucesso. No entanto, outra subclasse, LicitacaoEletronica, sobrescreve o método iniciar() mas, em certas condições, lança uma exceção de Processo Inválido que não está presente na assinatura do método da classe base Licitacao.O seguinte princípio SOLID está sendo violado pela classe LicitacaoEletronica, quebrando a expectativa de que um objeto da subclasse possa ser substituído por um objeto da superclasse sem alterar a corretude do programa:
APrincípio da Responsabilidade Única (SRP).
BPrincípio do Aberto/Fechado (OCP).
CPrincípio da Substituição de Liskov (LSP).
DPrincípio da Segregação de Interfaces (ISP).
EPrincípio da Inversão de Dependência (DIP).
Revelar gabarito e comentário▾
GabaritoC — Princípio da Substituição de Liskov (LSP).
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”.
Princípio da Substituição de Liskov (LSP)
Gabarito: letra C. O problema descrito — uma subclasse que sobrescreve um método e lança uma exceção não declarada na assinatura do método da classe base — viola diretamente o Princípio da Substituição de Liskov (LSP). Esse princípio estabelece que objetos de uma subclasse devem ser substituíveis por objetos da superclasse sem alterar a corretude do programa. Ao introduzir uma exceção inesperada, a subclasse quebra o contrato estabelecido pela classe base.
A banca testa o conhecimento dos cinco princípios SOLID e a capacidade de identificar qual deles é violado em um cenário específico de herança e polimorfismo.
Princípio SOLID
Descrição
Relação com o Cenário
Violado?
Responsabilidade Única (SRP)
Uma classe deve ter apenas um motivo para mudar
O cenário não menciona múltiplas responsabilidades
❌ Não
Aberto/Fechado (OCP)
Classes abertas para extensão, fechadas para modificação
O problema não é sobre modificar código existente
❌ Não
Substituição de Liskov (LSP)
Subclasses devem ser substituíveis por suas superclasses
LicitacaoEletronica lança exceção não prevista na classe base, quebrando a substituibilidade
✅ Sim
Segregação de Interfaces (ISP)
Clientes não devem depender de interfaces que não usam
Não há interfaces amplas ou dependências desnecessárias
❌ Não
Inversão de Dependência (DIP)
Depender de abstrações, não de implementações concretas
A violação não está relacionada a dependências entre módulos
❌ Não
Princípios SOLID: SRP (Responsabilidade Única) (Uma razão para mudar); OCP (Aberto/Fechado) (Aberto para extensão, Fechado para modificação); LSP (Substituição de Liskov) (Subclasse substitui superclasse, Exceção inesperada quebra contrato); ISP (Segregação de Interfaces) (Não forçar dependências desnecessárias); DIP (Inversão de Dependência) (Depender de abstrações)
Alternativa A — ❌ Incorreta
O Princípio da Responsabilidade Única (SRP) trata de uma classe ter apenas uma razão para mudar. A situação descrita não envolve múltiplas responsabilidades, mas sim a violação do contrato de herança.
Alternativa B — ❌ Incorreta
O Princípio do Aberto/Fechado (OCP) preconiza que classes devem estar abertas para extensão, mas fechadas para modificação. O problema não está relacionado à modificação de código existente, mas à substituição inadequada de objetos.
Alternativa C — ✅ Correta ⟵ GABARITO
O Princípio da Substituição de Liskov (LSP) é o violado. A subclasse LicitacaoEletronica ao lançar uma exceção não prevista na classe base Licitacao impede que objetos dessa subclasse sejam usados de forma transparente onde se espera um objeto da superclasse. Isso quebra o polimorfismo e a previsibilidade do código.
Alternativa D — ❌ Incorreta
O Princípio da Segregação de Interfaces (ISP) afirma que clientes não devem ser forçados a depender de interfaces que não usam. O caso não envolve interfaces amplas ou dependências desnecessárias.
Alternativa E — ❌ Incorreta
O Princípio da Inversão de Dependência (DIP) trata de depender de abstrações e não de implementações concretas. A violação descrita não está relacionada a dependências entre módulos.
NÃO CAIA NESSA!
A banca pode confundir o candidato entre LSP e OCP, já que ambos tratam de extensão. A chave é: LSP foca na substituibilidade do objeto (contrato), enquanto OCP foca em extensão sem modificar código-fonte. Aqui, o problema é quebrar o contrato ao lançar exceção não declarada — puro LSP.
Gabarito: letra C — Princípio da Substituição de Liskov (LSP) violado.