Questão de Engenharia de Software — Orientação a Objetos — FUNDATEC 2025
Engenharia de Software›Orientação a Objetos
Código
qg474977
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Em sistema crítico do Banco Central do Brasil, deseja-se reduzir acoplamento e aumentar flexibilidade do design OO, respeitando o Princípio da Substituição de Liskov (Liskov Substitution Principle - LSP). Assinale a alternativa que segue o LSP corretamente.
APreferir herança para qualquer reúso, pois evita a criação de objetos colaboradores.
BFavorecer a composição e o uso de herança apenas quando a subtipagem é estável e compatível com o LSP.
CAdotar herança múltipla em C# para compartilhar implementação entre várias classes base.
DExpor estado interno (internals) para facilitar extensões por subclasses.
EEvitar interfaces para reduzir o número de tipos e a complexidade do design.
Revelar gabarito e comentário▾
GabaritoB — Favorecer a composição e o uso de herança apenas quando a subtipagem é estável e compatível com o 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 B. O Princípio da Substituição de Liskov (LSP) estabelece que subtipos devem ser substituíveis por seus tipos base sem alterar a corretude do programa. A alternativa B corretamente destaca que a herança só deve ser usada quando a subtipagem é estável e compatível com o LSP, favorecendo a composição como prática mais segura para reduzir acoplamento e aumentar flexibilidade.
A banca testa o conhecimento do LSP juntamente com a recomendação de favorecer composição sobre herança (um princípio clássico de design orientado a objetos, originado no GoF). Vamos analisar cada alternativa:
LSP (Liskov Substitution Principle): Subtipo substituível pelo tipo base (Sem alterar corretude do programa); Prática recomendada (Favorecer composição, Herança só com subtipagem estável); Violações comuns (Herança para qualquer reúso, Expor estado interno, Evitar interfaces)
Alternativa A — ❌ Incorreta
Afirma que se deve "preferir herança para qualquer reúso", o que é uma generalização indevida. Herança é uma forma forte de acoplamento e, quando usada indiscriminadamente, frequentemente viola o LSP. O reúso deve priorizar composição, que é mais flexível e mantém o baixo acoplamento.
Alternativa B — ✅ Correta ⟵ GABARITO
A alternativa reflete exatamente a prática recomendada: "favorecer a composição e o uso de herança apenas quando a subtipagem é estável e compatível com o LSP". Isso está alinhado com os princípios SOLID e com o design orientado a objetos maduro.
Alternativa C — ❌ Incorreta
C# não suporta herança múltipla de classes (apenas herança simples e múltiplas interfaces). Além disso, herança múltipla aumenta a complexidade e não é uma solução para o LSP; pelo contrário, pode criar ambiguidades e violar o princípio se não for cuidadosamente projetada.
Alternativa D — ❌ Incorreta
Expor o estado interno (internals) para subclasses quebra o encapsulamento e pode levar a violações do LSP, pois subclasses podem depender de detalhes de implementação da classe base, tornando a substituição insegura.
Alternativa E — ❌ Incorreta
Evitar interfaces reduz a abstração e dificulta a aplicação do LSP. Interfaces são essenciais para definir contratos que permitem a substituição polimórfica. A eliminação de interfaces aumenta o acoplamento e reduz a flexibilidade do design.
NÃO CAIA NESSA!
A alternativa A pode enganar candidatos que acreditam que herança deve ser preferida para todo reúso, o que é uma generalização indevida e viola o LSP na maioria dos casos. O LSP exige que a herança seja usada com cautela, apenas quando a relação "é-um" é verdadeira e o comportamento da classe base é preservado.