Engenharia Múltipla Escolha

Na implementação de um processo complexo, um módulo A chama operações de um módulo B e de um módulo C. B, por sua vez, chama operações de C e de D. O módulo D chama operações de A e de E. Esse cenário ilustra uma interação entre objetos no estilo muitos para muitos. Para simplificar esse processo, define-se um objeto que centraliza todas as interações entre esses objetos, de modo que eles passam a se comunicar apenas com esse elemento central. Dessa forma, o elemento central X passa a receber uma notificação de A, para então chamar operações de B e C. Da mesma maneira, a partir de uma notificação enviada por B, X chama operações de C e de D.

Na implementação de um processo complexo, um módulo A chama operações de um módulo B e de um módulo C. B, por sua vez, chama operações de C e de D. O módulo D chama operações de A e de E. Esse cenário ilustra uma interação entre objetos no estilo muitos para muitos. Para simplificar esse processo, define-se um objeto que centraliza todas as interações entre esses objetos, de modo que eles passam a se comunicar apenas com esse elemento central. Dessa forma, o elemento central X passa a receber uma notificação de A, para então chamar operações de B e C. Da mesma maneira, a partir de uma notificação enviada por B, X chama operações de C e de D.

  1. Chain of Responsibility
  2. Strategy
  3. Visitor
  4. Template Method
  5. Mediator

Resolução completa

Explicação passo a passo

E
Alternativa E

Alternativa E - Mediator

Introdução

O enunciado descreve um clássico problema de arquitetura de software: a alta complexidade gerada quando muitos objetos precisam se comunicar diretamente uns com os outros. Para resolver isso, o texto propõe a criação de um objeto central que atua como intermediário.

Essa descrição define exatamente o Padrão de Projeto Mediator.

Desenvolvimento

O Problema: "Muitos para Muitos"

No cenário inicial descrito, temos um acoplamento direto entre módulos (ex: Módulo A chama B e C; Módulo B chama C e D).

  • Isso cria uma teia de dependências complexa.
  • Se um módulo muda, pode quebrar vários outros.
  • A manutenção torna-se difícil.

A Solução: O Mediador

O padrão Mediator introduz um objeto (neste caso, o elemento central X) que encapsula como um conjunto de objetos interage.

  • Centralização: As comunicações diretas são substituídas por chamadas ao mediador.
  • Desacoplamento: Os objetos não precisam saber detalhes dos outros objetos, apenas do mediador.
  • Exemplo prático: Em interfaces gráficas (GUIs), botões não se comunicam diretamente entre si para mudar cores; eles falam com o gerenciador da janela (mediador).

Análise das Alternativas

AlternativaConceito PrincipalPor que não se aplica?
AChain of ResponsibilityEncadeia requisições em uma lista de handlers. Não há centralização total de interações.
BStrategyPermite trocar algoritmos em tempo de execução. Foca no comportamento, não na comunicação.
CVisitorPermite adicionar novas operações a estruturas de objetos. Não trata de controle de fluxo.
DTemplate MethodDefine o esqueleto de um algoritmo em uma classe base. Padrão comportamental diferente.
EMediatorCorreto. Centraliza a comunicação para reduzir acoplamento entre objetos.

Conclusão

A descrição de um objeto central que simplifica a interação entre diversos módulos, evitando que eles se comuniquem diretamente ("muitos para muitos"), é a definição canônica do padrão Mediator. Portanto, a alternativa correta é a E.

Tem outra questão para resolver?

Resolver agora com IA

Mais questões de Engenharia

Ver mais Engenharia resolvidas

Tem outra questão de Engenharia?

Cole o enunciado, tire uma foto ou descreva o problema — a IA resolve com explicação completa em segundos.