Padrões de Projeto – Observer
Gabarito: letra B (Observer). O padrão Observer define uma dependência um-para-muitos entre objetos, de modo que quando um objeto (sujeito) muda de estado, todos os seus dependentes (observadores) são notificados e atualizados automaticamente. Esse é o padrão ideal para implementar um sistema de notificações de eventos processuais, pois permite adicionar novos tipos de notificação (novos observadores) sem modificar o código do sujeito ou dos notificadores existentes, atendendo ao requisito de flexibilidade.
A questão cobra o conhecimento dos padrões de projeto GoF (Gang of Four) e sua aplicação a um problema de notificação. Vejamos cada alternativa:
Padrão de Projeto | Categoria | Propósito Principal | Adequação ao Sistema de Notificação |
|---|
Singleton | Criacional | Garantir uma única instância e acesso global | ❌ Não resolve notificação de múltiplos eventos |
Observer | Comportamental | Definir dependência um-para-muitos para notificação automática | ✅ Ideal: sujeito notifica observadores sobre eventos |
Strategy | Comportamental | Encapsular algoritmos intercambiáveis | ❌ Não modela propagação de eventos |
Factory Method | Criacional | Delegar criação de objetos a subclasses | ❌ Foco em criação, não em notificação |
Decorator | Estrutural | Adicionar responsabilidades dinamicamente | ❌ Não é o padrão natural para notificações |
Alternativa A — ❌ Incorreta
Singleton garante que uma classe tenha apenas uma instância e fornece um ponto global de acesso a ela. Não resolve o problema de notificação de múltiplos eventos para múltiplos destinatários; seu foco é controle de instância.
Alternativa B — ✅ Correta ⟵ GABARITO
Observer é o padrão comportamental que estabelece um mecanismo de assinatura para notificar múltiplos objetos sobre eventos ocorridos em outro objeto. Exatamente o que o enunciado descreve: eventos processuais (sujeito) e interessados (observadores) que recebem notificações. A adição de novos tipos de notificação corresponde a criar novos observadores, sem alterar a estrutura existente.
Alternativa C — ❌ Incorreta
Strategy permite definir uma família de algoritmos, encapsulá-los e torná-los intercambiáveis. É usado para variar o comportamento de um objeto em tempo de execução, mas não modela a propagação de eventos para múltiplos destinatários.
Alternativa D — ❌ Incorreta
Factory Method define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe instanciar. É um padrão criacional, não adequado para notificação de eventos.
Alternativa E — ❌ Incorreta
Decorator atribui responsabilidades adicionais a um objeto dinamicamente, fornecendo uma alternativa flexível à herança para extensão de funcionalidade. Embora possa ser usado para adicionar comportamentos, não é o padrão mais natural para um sistema de notificação baseado em eventos; o Observer é a escolha direta.
Conclusão: O padrão Observer é o mais adequado para implementar um sistema de notificações flexível e com baixo acoplamento, conforme exigido pelo enunciado. Gabarito: letra B.