Questão de Engenharia de Software — Geral — FCC 2026
Engenharia de Software›Geral
Código
fc142283
Banca
FCC
Órgão
ARTESP
Ano
2026
Cargo
Esp RT ( )
Uma agência reguladora de transporte intermunicipal precisa implementar um sistema de notificação que alerte diferentes órgãos fiscalizadores (Polícia Rodoviária, ANTT, Secretarias Municipais) sempre que uma infração grave for registrada. Cada órgão possui seu próprio formato de recebimento de notificações e pode ser adicionado ou removido dinamicamente do sistema conforme convênios estabelecidos. O especialista precisa escolher o padrão de projeto mais adequado para implementar esse mecanismo de notificação. Considerando as características do problema apresentado, o padrão que melhor se aplica é:
AAdapter, que converte a interface do sistema de infrações para formatos específicos exigidos por cada órgão fiscalizador, permitindo que componentes incompatíveis colaborem através de camada intermediária de adaptação, facilitando integração com sistemas legados mediante tradução transparente de estruturas de dados heterogêneas.
BObserver, que estabelece relação um-para-muitos entre o objeto emissor de infrações e os órgãos observadores, permitindo que múltiplos fiscalizadores sejam notificados automaticamente quando houver mudança de estado no registro de infrações, mantendo baixo acoplamento entre notificador e destinatários através de interface comum de atualização.
CStrategy, que encapsula diferentes algoritmos de notificação em classes separadas para cada órgão fiscalizador, possibilitando alternar dinamicamente entre estratégias de envio conforme características específicas de cada destinatário, mantendo flexibilidade na escolha do comportamento de notificação através de interface comum de execução.
DFactory Method, que define interface para criação de objetos de notificação, delegando às subclasses concretas a decisão sobre qual tipo de notificação instanciar para cada órgão, promovendo extensibilidade ao adicionar novos fiscalizadores através de implementação de novas fábricas especializadas na geração de alertas personalizados.
ESingleton, que garante a existência de instância única do gerenciador de notificações durante execução do sistema, centralizando controle de envio para todos os órgãos fiscalizadores através de ponto global de acesso, assegurando consistência na distribuição de alertas mediante coordenação centralizada das comunicações regulatórias.
Revelar gabarito e comentário▾
GabaritoB — Observer, que estabelece relação um-para-muitos entre o objeto emissor de infrações e os órgãos observadores, permitindo que múltiplos fiscalizadores sejam notificados automaticamente quando houver mudança de estado no registro de infrações, mantendo baixo acoplamento entre notificador e destinatários através de interface comum de atualização.
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: Observer
Gabarito: letra B. O padrão Observer é o mais adequado porque o problema exige uma relação um-para-muitos entre o emissor de infrações (sujeito) e os órgãos fiscalizadores (observadores), que devem ser notificados automaticamente quando o estado do registro de infrações mudar, com baixo acoplamento entre eles — exatamente o que a alternativa B descreve. A fonte é o catálogo GoF (Gang of Four), que define o Observer como o padrão de comportamento para propagação de mudanças de estado.
O padrão Observer (ou Observador) é um padrão de projeto comportamental que define uma dependência um-para-muitos entre objetos, de modo que quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente. No cenário da questão, o "sujeito" é o sistema de registro de infrações; os "observadores" são os órgãos fiscalizadores (Polícia Rodoviária, ANTT, Secretarias Municipais). Cada órgão pode ser adicionado ou removido dinamicamente — o Observer permite exatamente isso, pois o sujeito mantém uma lista de observadores e oferece métodos para anexar/desanexar. Além disso, o baixo acoplamento é garantido porque o sujeito conhece apenas a interface comum Observer (com o método update()), não as classes concretas de cada órgão. Isso atende perfeitamente à necessidade de notificar múltiplos destinatários com formatos próprios, sem que o emissor precise conhecer os detalhes de cada um.
Para entender por que as outras alternativas não se aplicam, é preciso distinguir os padrões:
Adapter: converte a interface de uma classe em outra interface esperada pelos clientes, permitindo que classes incompatíveis trabalhem juntas. Ele resolve problemas de incompatibilidade de interfaces, não de notificação em massa.
Strategy: encapsula algoritmos intercambiáveis, permitindo que o cliente escolha o comportamento em tempo de execução. Ele é útil quando há várias maneiras de executar uma mesma tarefa, mas não estabelece uma relação de notificação automática.
Factory Method: define uma interface para criar objetos, deixando as subclasses decidirem qual classe instanciar. Ele trata da criação de objetos, não da comunicação entre eles.
Singleton: garante uma única instância de uma classe, fornecendo um ponto de acesso global. Ele resolve problemas de instância única, não de notificação a múltiplos destinatários.
A pegadinha da banca está em confundir o Observer com o Strategy ou com o Adapter. O Observer é o único que estabelece a relação um-para-muitos com notificação automática. O Strategy até menciona "alternar dinamicamente", mas isso se refere à troca de algoritmos, não à notificação de múltiplos observadores. O Adapter fala em "converter interfaces", o que é um problema de integração, não de propagação de eventos.
Na prática, imagine que uma infração grave é registrada. O sistema (sujeito) notifica todos os órgãos cadastrados (observadores) chamando o método update() de cada um. Se um novo convênio é firmado com uma Secretaria Municipal, basta adicioná-la à lista de observadores; se um convênio termina, remove-se. Nenhum órgão precisa conhecer os outros, e o sistema não precisa ser alterado para incluir novos tipos de órgãos — basta que eles implementem a interface Observer. Isso é exatamente o que o problema pede.
Guarde a fronteira: Observer = notificação automática de múltiplos interessados; Strategy = troca de algoritmos; Adapter = compatibilização de interfaces; Factory Method = criação de objetos; Singleton = instância única. É nessa fronteira que as alternativas se dividem.
Padrões de projeto (GoF)
1Comportamentais
Observer
Relação 1:N
Notificação automática
Baixo acoplamento
Strategy
Troca de algoritmos
2Estruturais
Adapter
Compatibiliza interfaces
3Criacionais
Factory Method
Criação de objetos
Singleton
Instância única
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
O Adapter é um padrão estrutural que converte a interface de uma classe em outra interface esperada pelos clientes, permitindo que classes incompatíveis trabalhem juntas. No problema, não há incompatibilidade de interfaces entre o sistema de infrações e os órgãos — o que se quer é notificar múltiplos órgãos quando uma infração é registrada. O Adapter não estabelece relação um-para-muitos nem notificação automática; ele apenas traduz chamadas de interface. A descrição da alternativa até menciona "camada intermediária de adaptação", mas isso não resolve o requisito de notificação dinâmica.
Alternativa B — ✅ Correta ⟵ GABARITO
O Observer é o padrão comportamental que define uma dependência um-para-muitos entre objetos, de modo que quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente. No cenário, o sistema de infrações é o sujeito; os órgãos fiscalizadores são os observadores. A alternativa descreve com precisão: "relação um-para-muitos", "notificados automaticamente quando houver mudança de estado", "baixo acoplamento através de interface comum de atualização". Isso atende exatamente aos requisitos de adicionar/remover órgãos dinamicamente e de cada órgão ter seu próprio formato de recebimento (via implementação da interface Observer).
Alternativa C — ❌ Incorreta
O Strategy é um padrão comportamental que encapsula algoritmos intercambiáveis, permitindo que o cliente escolha o comportamento em tempo de execução. Ele é útil quando há várias maneiras de executar uma mesma tarefa (ex.: diferentes algoritmos de ordenação). No problema, não se trata de escolher entre algoritmos de notificação, mas de notificar múltiplos destinatários quando um evento ocorre. O Strategy não estabelece relação um-para-muitos nem notificação automática; ele apenas permite alternar entre estratégias de envio, o que não resolve o requisito de notificar todos os órgãos simultaneamente.
Alternativa D — ❌ Incorreta
O Factory Method é um padrão criacional que define uma interface para criar objetos, deixando as subclasses decidirem qual classe instanciar. Ele resolve problemas de criação de objetos, não de comunicação entre eles. No problema, o foco é a notificação de órgãos já existentes, não a criação de novos tipos de notificação. Embora a alternativa mencione "extensibilidade ao adicionar novos fiscalizadores", isso se refere à criação de objetos, não à propagação de eventos. O Observer já permite adicionar novos observadores sem alterar o sujeito, mas o Factory Method não estabelece a relação um-para-muitos necessária.
Alternativa E — ❌ Incorreta
O Singleton é um padrão criacional que garante a existência de uma única instância de uma classe, fornecendo um ponto de acesso global. Ele resolve problemas de instância única, não de notificação a múltiplos destinatários. No problema, não há requisito de instância única; pelo contrário, há necessidade de múltiplos órgãos sendo notificados. A alternativa até menciona "coordenação centralizada", mas isso não é o que o problema pede — o problema pede notificação automática a múltiplos interessados, o que é papel do Observer.
Gabarito: letra B — o padrão Observer é o que melhor se aplica ao cenário de notificação de múltiplos órgãos fiscalizadores.