Questão de Arquitetura de Software — Arquitetura Orientada a Objetos — Instituto Legalle 2026
Arquitetura de Software›Arquitetura Orientada a Objetos
Código
qg747488
Banca
Instituto Legalle
Órgão
BADESUL - RS
Ano
2026
Nível
Superior
Cargo
Técnico em Desenvolvimento - Analista de Sistemas (Ênfase em Arquiteto de Software)
No contexto dos princípios SOLID, que orientam o desenvolvimento de software orientado a objetos, assinale a alternativa que NÃO corresponde a um dos princípios do SOLID.
AUma classe deve ter apenas um motivo para mudar.
BEntidades devem estar abertas para extensão, mas fechadas para modificação.
CObjetos de uma classe base devem poder ser substituídos por objetos de subclasses sem alterar o comportamento esperado.
DClientes não devem ser forçados a depender de métodos que não utilizam.
EClasses devem depender diretamente de implementações concretas, evitando o uso de abstrações.
Revelar gabarito e comentário▾
GabaritoE — Classes devem depender diretamente de implementações concretas, evitando o uso de abstrações.
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
Gabarito: letra E. A alternativa E descreve o oposto do Princípio da Inversão de Dependência (DIP), que determina que módulos de alto e baixo nível devem depender de abstrações, e não de implementações concretas. As demais alternativas correspondem corretamente aos princípios SRP, OCP, LSP e ISP, respectivamente.
A banca cobra o conhecimento do acrônimo SOLID e de cada princípio. Questão clássica: a pegadinha está em identificar qual alternativa foge ao conjunto.
NÃO CAIA NESSA!
O enunciado pede a alternativa que NÃO corresponde a um princípio SOLID. Cuidado: as quatro primeiras são descrições fiéis; a E inverte o DIP. Leia sempre o comando: "assinale a que NÃO corresponde" — se você marcar uma correta, erra a questão.
Princípio SOLID
Descrição Correta
Descrição da Alternativa
Corresponde ao SOLID?
SRP (Single Responsibility Principle)
Uma classe deve ter apenas um motivo para mudar
Uma classe deve ter apenas um motivo para mudar (Alternativa A)
Sim
OCP (Open/Closed Principle)
Entidades abertas para extensão, fechadas para modificação
Entidades devem estar abertas para extensão, mas fechadas para modificação (Alternativa B)
Sim
LSP (Liskov Substitution Principle)
Subtipos devem ser substituíveis por seus tipos base
Objetos de uma classe base devem poder ser substituídos por objetos de subclasses sem alterar o comportamento esperado (Alternativa C)
Sim
ISP (Interface Segregation Principle)
Clientes não devem depender de interfaces que não usam
Clientes não devem ser forçados a depender de métodos que não utilizam (Alternativa D)
Sim
DIP (Dependency Inversion Principle)
Módulos devem depender de abstrações, não de implementações concretas
Classes devem depender diretamente de implementações concretas, evitando o uso de abstrações (Alternativa E)
Não (inverte o princípio)
Alternativa A — ✅ Correta
Descreve o Single Responsibility Principle (SRP): uma classe deve ter apenas um motivo para mudar, ou seja, uma única responsabilidade. Esta é a definição clássica do SRP.
Alternativa B — ✅ Correta
Descreve o Open/Closed Principle (OCP): entidades devem estar abertas para extensão, mas fechadas para modificação. O comportamento é estendido sem alterar o código existente.
Alternativa C — ✅ Correta
Descreve o Liskov Substitution Principle (LSP): subtipos devem poder substituir seus tipos base sem quebrar o programa. Objetos de uma subclasse devem ser substituíveis por objetos da superclasse sem alterar o comportamento esperado.
Alternativa D — ✅ Correta
Descreve o Interface Segregation Principle (ISP): clientes não devem ser forçados a depender de interfaces que não usam. Interfaces grandes e coesas devem ser segregadas em interfaces menores e específicas.
Alternativa E — ❌ Incorreta ⟵ GABARITO
Afirma que "classes devem depender diretamente de implementações concretas, evitando o uso de abstrações". Isso contradiz frontalmente o Dependency Inversion Principle (DIP), que diz exatamente o oposto: "Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações." e "Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações." Logo, a alternativa E é a única que não representa um princípio SOLID.
NÃO CAIA NESSA!
Decore o acrônimo SOLID e a frase-chave de cada um: S = uma razão; O = aberto para extensão, fechado para modificação; L = substituição de subtipos; I = interfaces segregadas; D = inverter dependências (abstrações, não concretos). Nas provas, a banca costuma inverter o DIP como nesta questão.