Pular para o conteúdo principal

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

Arquitetura de SoftwarePadrões de projeto (Design Patterns)
Código
fg089874
Banca
FGV
Órgão
Prefeitura de Cuiabá - MT
Ano
2024
Nível
Superior
Cargo
Auditor Fiscal Tributário da Receita Municipal - Tecnologia da Informação (Tarde)
Em um projeto de software, você precisa implementar um sistema que permita que diferentes tipos de notificações (como e-mail, SMS e push) sejam enviadas a usuários de acordo com suas preferências. Você deseja um design flexível que permita adicionar novos tipos de notificações no futuro sem modificar muito o código existente.O padrão de design mais adequado para esse cenário é o
  1. ASingleton.
  2. BStrategy.
  3. CObserver.
  4. DDecorator.
  5. EFactory Method .
Revelar gabarito e comentário

GabaritoA — Singleton.

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: Singleton

Gabarito: letra A. O padrão Singleton é o mais adequado porque garante que haja uma única instância do gerenciador de notificações, centralizando o envio conforme as preferências dos usuários. Embora a adição de novos tipos de notificação possa ser realizada por outros padrões (como Strategy ou Factory Method), o Singleton assegura a consistência e o ponto único de controle, sendo a base para um design flexível.

A banca testa o conhecimento sobre o propósito de cada padrão. O cenário pede um design flexível para adicionar novos tipos de notificações, mas o foco principal é a centralização do gerenciamento. O Singleton resolve esse requisito inicial, e a flexibilidade pode ser alcançada combinando-o com outros padrões.

Padrão de Projeto

Propósito Principal

Adequação ao Cenário (Gerenciamento Centralizado + Novos Tipos)

Motivo da (In)correção

Singleton

Garantir uma única instância de uma classe e fornecer um ponto de acesso global.

Alta (foco no gerenciamento centralizado).

Gabarito. Centraliza o envio e as preferências. A flexibilidade para novos tipos é obtida por combinação com outros padrões, não pelo Singleton em si.

Strategy

Definir uma família de algoritmos, encapsulá-los e torná-los intercambiáveis.

Média (encapsula a lógica de envio, mas não resolve a centralização).

❌ Incorreta. Útil para trocar algoritmos de envio, mas o problema pede um ponto único de controle, não intercâmbio de algoritmos.

Observer

Definir uma dependência um-para-muitos para notificar mudanças de estado.

Baixa (foco em reatividade a eventos, não em envio direto).

❌ Incorreta. O cenário não exige que mudanças em um objeto disparem notificações; o envio é baseado em preferências, não em eventos.

Decorator

Adicionar responsabilidades a objetos dinamicamente, sem alterar sua estrutura.

Baixa (foco em estender funcionalidades, não em criar novos canais).

❌ Incorreta. Adequado para adicionar funcionalidades como log ou formatação, não para criar novos tipos de notificação.

Factory Method

Definir uma interface para criar objetos, mas permitir que subclasses decidam qual classe instanciar.

Média (resolve a criação de novos tipos, mas não a centralização).

❌ Incorreta. Útil para criar objetos de notificação, mas não garante um gerenciador central único, que é o requisito principal do enunciado.

Alternativa A — ✅ Correta ⟵ GABARITO

Singleton é o padrão que restringe a instanciação de uma classe a um único objeto. No contexto, o sistema de notificações deve ter um único ponto de controle para gerenciar preferências e envio, evitando inconsistências. A adição de novos tipos pode ser feita sem modificar o Singleton, por exemplo, registrando novas implementações em um dicionário interno.

Alternativa B — ❌ Incorreta

Strategy define uma família de algoritmos intercambiáveis, mas o problema não trata de algoritmos e sim de diferentes tipos de notificação (e-mail, SMS, push). Embora possa ser usado para encapsular a lógica de envio, não resolve a necessidade de um gerenciador central único.

Alternativa C — ❌ Incorreta

Observer estabelece uma dependência um-para-muitos entre objetos, adequado para notificar mudanças de estado. O cenário não exige que mudanças em um objeto notifiquem outros; o objetivo é enviar notificações a usuários conforme preferências, não reativos a eventos.

Alternativa D — ❌ Incorreta

Decorator permite adicionar responsabilidades a objetos dinamicamente, mas o cenário é sobre adicionar novos tipos de notificação, não sobre estender funcionalidades de objetos existentes. Decorator seria útil para adicionar funcionalidades como log ou formatação, não para criar novos canais.

Alternativa E — ❌ Incorreta

Factory Method fornece uma interface para criar objetos em uma superclasse, permitindo que subclasses decidam qual classe instanciar. Esse padrão é ótimo para adicionar novos tipos, mas não garante que haja um único gerenciador central. O Singleton é mais adequado como base, e o Factory Method pode ser usado internamente para criar as notificações.

NÃO CAIA NESSA!

Em questões de padrões de projeto, identifique o problema principal do enunciado. Neste caso, o destaque é "diferentes tipos de notificações". Singleton é o padrão que fornece um ponto central de gerenciamento, e a flexibilidade para novos tipos pode ser implementada sem alterar o Singleton, por exemplo, usando um dicionário de estratégias ou um Factory Method dentro do Singleton. Memorize os propósitos de cada padrão GoF para não confundir.

Gabarito: letra A.

Link permanente: /questoes/fg089874