Questão de Arquitetura de Software — Padrões de projeto (Design Patterns) — CESGRANRIO 2025
Arquitetura de Software›Padrões de projeto (Design Patterns)
Código
cg023489
Banca
CESGRANRIO
Órgão
BANESE
Ano
2025
Nível
Médio
Cargo
Técnico Bancário III - Desenvolvimento
Uma empresa especializada no desenvolvimento de aplicações empresariais escaláveis enfrenta dificuldades na manutenção do seu código devido ao alto acoplamento entre classes. Os desenvolvedores perceberam que muitas classes criam instâncias de seus próprios objetos dependentes, dificultando os testes unitários, a reutilização de código e a troca de implementações sem afetar outras partes do sistema. Para resolver esse problema, o arquiteto de software sugere o uso do padrão Injeção de Dependências (Dependency Injection – DI).A sugestão do arquiteto sobre o uso de Injeção de Dependências (DI) considera que esse padrão
Acria manualmente todas as instâncias de objetos dentro das classes para garantir total controle sobre suas dependências.
Belimina demandas por composição de objetos e por extensibilidade das aplicações, facilitando o gerenciamento do ciclo de vida.
Cinjeta dependências estáveis, que ainda estão em desenvolvimento e que têm comportamento não determinístico, no construtor das classes.
Dpermite que dependências sejam passadas externamente para um objeto, reduzindo o acoplamento e facilitando a testabilidade.
Eutiliza verificações de erro em tempo de execução para capturar falhas de comunicação entre objetos dependentes.
Revelar gabarito e comentário▾
GabaritoD — permite que dependências sejam passadas externamente para um objeto, reduzindo o acoplamento e facilitando a testabilidade.
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”.
Injeção de Dependências (Dependency Injection)
Gabarito: letra D. A Injeção de Dependências é um padrão de projeto que reduz o acoplamento ao externalizar a criação de dependências, passando-as para o objeto de fora, o que facilita a substituição de implementações e os testes unitários. É exatamente o que a alternativa D descreve.
A banca testa o conceito central de DI: ela consiste em fornecer as dependências de um objeto externamente, em vez de ele mesmo criá-las. Isso promove baixo acoplamento e alta testabilidade.
Injeção de Dependências (DI): Objetivo (Reduzir acoplamento, Facilitar testabilidade, Aumentar extensibilidade); Mecanismo (Dependências passadas externamente, Inversão de controle (IoC), Container ou injetor); O que NÃO é (Criar instâncias dentro da classe, Eliminar composição/extensibilidade, Verificação de erros em execução)
Alternativa A — ❌ Incorreta
Afirma que DI cria manualmente todas as instâncias dentro das classes. Isso é o oposto do padrão: DI inverte o controle da criação, delegando-a a um container ou injetor. Criar dependências internamente gera alto acoplamento, justamente o problema que DI busca resolver.
Alternativa B — ❌ Incorreta
Diz que DI elimina demandas por composição e extensibilidade. Na verdade, DI promove a composição de objetos (ao injetar dependências) e aumenta a extensibilidade, pois permite trocar implementações sem alterar o consumidor. A frase é contrária aos benefícios do padrão.
Alternativa C — ❌ Incorreta
Menciona "injetar dependências estáveis que ainda estão em desenvolvimento e com comportamento não determinístico". Isso é confuso e não representa uma característica de DI. A injeção pode ser aplicada a dependências estáveis ou não, mas o foco do padrão é como a dependência é fornecida, não a natureza dela. Além disso, "comportamento não determinístico" não é um conceito relacionado a DI.
Alternativa D — ✅ Correta ⟵ GABARITO
A descrição é precisa: DI permite que dependências sejam passadas externamente para um objeto, reduzindo o acoplamento e facilitando a testabilidade. Esse é o cerne do padrão — também conhecido como princípio da inversão de controle (IoC) aplicado à injeção.
Alternativa E — ❌ Incorreta
Associa DI a verificações de erro em tempo de execução para capturar falhas de comunicação. DI não trata de detecção de falhas; trata-se de prover dependências. O tratamento de erros é uma preocupação separada, não faz parte do padrão.
PEGA ESSA DICA!
Para fixar: Injeção de Dependências é sobre quem cria a dependência. No código acoplado, a classe cria suas dependências (new Servico()). Com DI, as dependências são recebidas por parâmetro (construtor, setter ou interface). Isso é o que possibilita mockar objetos em testes e trocar implementações sem mexer na classe.