Pular para o conteúdo principal

Questão de Arquitetura de Software — Padrões de projeto (Design Patterns) — FGV 2025

Arquitetura de SoftwarePadrões de projeto (Design Patterns)
Código
fg105421
Banca
FGV
Órgão
AL-AM
Ano
2025
Nível
Superior
Cargo
Analista Legislativo - Programador
O Analista de Sistemas precisa projetar um módulo de cálculo de impostos para a Receita Federal onde o algoritmo de cálculo ICMS, ISS e IPI muda frequentemente, dependendo do estado ou do tipo de produto. O código deve ser flexível para aceitar novos algoritmos de cálculo sem modificar a classe principal de checkout.Assinale o Padrão de Projeto Comportamental que deve ser utilizado para definir uma família de algoritmos, encapsular cada um e torná-los intercambiáveis, permitindo que o cliente use o algoritmo de forma transparente.
  1. AFactory Method.
  2. BSingleton.
  3. CObserver.
  4. DAdapter.
  5. EStrategy.
Revelar gabarito e comentário

GabaritoE — Strategy.

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”.

Padrões de Projeto Comportamentais: Strategy

Gabarito: letra E (Strategy). O padrão Strategy é o único dentre as alternativas que se encaixa na definição de "definir uma família de algoritmos, encapsular cada um e torná-los intercambiáveis", permitindo que o cliente use o algoritmo de forma transparente sem modificar a classe principal. A FGV cobra exatamente esse conceito clássico do GoF.

A questão descreve um cenário em que o algoritmo de cálculo de impostos (ICMS, ISS, IPI) muda frequentemente conforme o estado ou tipo de produto. O objetivo é flexibilidade para aceitar novos algoritmos sem modificar a classe principal de checkout. Isso é a essência do padrão Strategy: cada algoritmo (cálculo de ICMS, ISS, IPI) é encapsulado em uma classe separada que implementa uma interface comum; a classe de checkout (contexto) delega o cálculo a uma dessas classes, podendo trocá-la em tempo de execução.

Padrões de projeto
  • 1Comportamentais
    • Strategy
      • Família de algoritmos
      • Encapsula cada um
      • Intercambiáveis
      • Cliente usa transparentemente
    • Observer
      • Notificação de mudanças
      • Relação um-para-muitos
  • 2Criacionais
    • Factory Method
      • Criação de objetos
      • Delegada a subclasses
    • Singleton
      • Única instância
      • Acesso global
  • 3Estruturais
    • Adapter
      • Converte interface
      • Integração de componentes
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Factory Method é um padrão criacional. Seu propósito é delegar a criação de objetos a subclasses, não encapsular algoritmos intercambiáveis. A confusão surge porque ambos podem envolver hierarquias de classes, mas o foco do Factory Method é como o objeto é instanciado, e não como o algoritmo é executado.

Alternativa B — ❌ Incorreta

Singleton é um padrão criacional que garante uma única instância de uma classe e fornece um ponto global de acesso. Não tem relação com algoritmos variáveis. Usar Singleton para os cálculos de imposto seria inadequado, pois cada algoritmo precisaria de uma instância diferente e intercambiável.

Alternativa C — ❌ Incorreta

Observer é um padrão comportamental, mas serve para notificar múltiplos objetos sobre mudanças de estado em outro objeto (relação um-para-muitos). Não se aplica a encapsular algoritmos; seu objetivo é manter consistência entre objetos dependentes.

Alternativa D — ❌ Incorreta

Adapter é um padrão estrutural que converte a interface de uma classe em outra interface esperada pelo cliente. Embora seja usado para integrar componentes com interfaces incompatíveis, não trata da troca de algoritmos; seu foco é adaptação de interfaces, não encapsulamento de comportamentos variáveis.

Alternativa E — ✅ Correta ⟵ GABARITO

O padrão Strategy é a solução adequada. Ele permite definir uma família de algoritmos, encapsular cada um em uma classe separada e torná-los intercambiáveis. A classe de checkout (contexto) mantém uma referência a um objeto Strategy e delega a ele o cálculo, podendo trocar o algoritmo em tempo de execução sem alterar seu código. Isso atende exatamente ao requisito de flexibilidade para novos impostos sem modificar a classe principal.

NÃO CAIA NESSA!

A banca pode induzir o candidato a escolher Factory Method (alternativa A) por ambos envolverem hierarquias de classes, mas o Strategy é o padrão que trata de algoritmos intercambiáveis, enquanto o Factory Method trata de criação de objetos. Fique atento ao verbo "calcular" e à necessidade de troca dinâmica de comportamento — isso é Strategy, não criação.

Gabarito: letra E.

Link permanente: /questoes/fg105421