Questão de Engenharia de Software — Orientação a Objetos — CESPE / CEBRASPE 2025
Engenharia de Software›Orientação a Objetos
Código
ce214862
Banca
CESPE / CEBRASPE
Órgão
SEFAZ-SE
Ano
2025
Nível
Superior
Cargo
Auditor Fiscal Tributário - Tecnologia da Informação
Em determinado projeto de software orientado a objetos, um desenvolvedor deve implementar um sistema que proteja partes do código de variações e mudanças frequentes em outros componentes, mantendo um baixo acoplamento entre as classes. Ao mesmo tempo, deseja-se que módulos de alto nível não dependam diretamente de módulos de baixo nível, mas que ambos dependam de abstrações.Nessa situação, o princípio de SOLID e o princípio de GRASP que atendem adequadamente aos requisitos mencionados são, respectivamente,
Ao princípio da substituição de Liskov e o princípio de indireção.
Bo princípio aberto-fechado e o princípio de alta coesão.
Co princípio da inversão de dependência e o princípio de variações protegidas.
Do princípio da responsabilidade única e o princípio especialista.
Eo princípio da segregação de interfaces e o princípio criador.
Revelar gabarito e comentário▾
GabaritoC — o princípio da inversão de dependência e o princípio de variações protegidas.
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ípios SOLID e GRASP
Gabarito: letra C. O cenário descreve claramente o princípio da Inversão de Dependência (DIP) do SOLID — módulos de alto nível não dependem de módulos de baixo nível, ambos dependem de abstrações — e o padrão GRASP de Variações Protegidas (Protected Variations), que isola partes do código que variam para evitar impacto em outros componentes. A alternativa C é a única que reúne exatamente esses dois princípios.
A banca testa o conhecimento tanto dos princípios SOLID quanto dos padrões GRASP, que frequentemente são confundidos entre si. O segredo da questão está em identificar que a descrição do enunciado corresponde literalmente a dois conceitos específicos.
NÃO CAIA NESSA!
A banca tenta confundir o candidato oferecendo pares que também envolvem baixo acoplamento ou extensão, como o par Aberto-Fechado + Alta Coesão (alternativa B). Enquanto o OCP foca em extensão sem modificação, o DIP trata da inversão das dependências. Já a Alta Coesão é sobre responsabilidades agrupadas, não sobre proteção contra variações. Fique atento às definições exatas.
SOLID
1DIP (Inversão de Dependência)
Alto nível não depende do baixo nível
Ambos dependem de abstrações
2GRASP
Variações Protegidas
Isola partes que variam
Baixo acoplamento
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Erro: Troca o princípio SOLID correto (DIP) pelo Princípio da Substituição de Liskov (LSP), que trata da substituibilidade de subtipos, e o GRASP correto (Variações Protegidas) por Indireção (Indirection), que visa reduzir acoplamento por meio de um objeto intermediário. Nenhum dos dois atende ao requisito de depender de abstrações ou de proteger partes das variações.
Alternativa B — ❌ Incorreta
Erro: Apresenta o Princípio Aberto-Fechado (OCP) e o padrão de Alta Coesão (High Cohesion). O OCP estabelece que classes devem estar abertas para extensão, mas fechadas para modificação, não abordando a inversão de dependências. A Alta Coesão busca manter responsabilidades bem agrupadas, não proteger contra variações externas. O par não corresponde ao enunciado.
Alternativa C — ✅ Correta ⟵ GABARITO
Acerto: A descrição do enunciado — "módulos de alto nível não dependam diretamente de módulos de baixo nível, mas que ambos dependam de abstrações" — é a definição exata do Dependency Inversion Principle (DIP), um dos cinco princípios SOLID. O trecho "proteja partes do código de variações e mudanças frequentes em outros componentes, mantendo um baixo acoplamento" descreve o padrão GRASP Protected Variations (ou Variações Protegidas), que visa isolar pontos de variação para minimizar o impacto de mudanças. Portanto, o par está correto.
Alternativa D — ❌ Incorreta
Erro: Substitui o DIP pelo Princípio da Responsabilidade Única (SRP) — que determina que uma classe deve ter apenas um motivo para mudar — e o padrão de Variações Protegidas por Especialista (Expert), que atribui responsabilidade a quem possui a informação necessária. Novamente, não atendem aos requisitos de dependência de abstrações e proteção contra variações.
Alternativa E — ❌ Incorreta
Erro: Apresenta o Princípio da Segregação de Interfaces (ISP) — que evita que clientes dependam de interfaces que não usam — e o padrão Criador (Creator), que define quem deve instanciar objetos. Nenhum dos dois se relaciona com a inversão de dependências ou com a proteção contra variações descritas no enunciado.