Um colega de trabalho está implementando a interface com o usuário de um sistema que dispara a execução de uma lógica de negócio envolvendo vários objetos. Ele implementa uma primeira versão que faz diversas chamadas a objetos de lógica de negócio porque não existe uma interface de mais alto nível disponível que encapsule esta complexidade. Para piorar, ao implementar um segundo módulo de interface com o usuário, ele se depara com o mesmo problema, tendo que copiar e colar partes da lógica utilizadas no primeiro módulo de interface com o usuário. Ao revisar o código feito pelo seu colega, qual padrão você recomendaria que ele utilizasse para diminuir o acoplamento entre os módulos de interface com o usuário e módulos referentes à lógica de negócio?

Question

Um colega de trabalho está implementando a interface com o usuário de um sistema que dispara a execução de uma lógica de negócio envolvendo vários objetos. Ele implementa uma primeira versão que faz diversas chamadas a objetos de lógica de negócio porque não existe uma interface de mais alto nível disponível que encapsule esta complexidade. Para piorar, ao implementar um segundo módulo de interface com o usuário, ele se depara com o mesmo problema, tendo que copiar e colar partes da lógica utilizadas no primeiro módulo de interface com o usuário. Ao revisar o código feito pelo seu colega, qual padrão você recomendaria que ele utilizasse para diminuir o acoplamento entre os módulos de interface com o usuário e módulos referentes à lógica de negócio? A) Proxy B) Composite C) Flyweight D) Adapter E) Facade

Sapien IA · Accepted Answer

Alternativa E Facade Análise da Questão O cenário apresentado descreve um problema clássico de acoplamento excessivo e complexidade desnecessária na comunicação entre a interface do usuário e a lógica de negócio. Por que a alternativa E é a correta? O padrão de projeto Facade (ou Fachada) tem como objetivo principal fornecer uma interface unificada e simplificada para um conjunto de interfaces em um subsistema complexo. No contexto da questão: Problema: A interface do usuário precisa chamar diversos objetos de negócio individualmente, criando dependência direta e código repetitivo. Solução (Facade): Criar uma classe "Fachada" que encapsula toda a lógica complexa. A interface do usuário apenas chama a fachada, que por sua vez orquestra as chamadas aos objetos de negócio. Resultado: Redução drástica do acoplamento e eliminação da duplicação de código entre os módulos de interface. Análise das outras alternativas Para entender melhor, vamos ver por que as outras opções não se encaixam neste cenário específico: | Padrão | Função Principal | Por que não se aplica aqui? | | : | : | : | | Proxy (A) | Controlar o acesso a um objeto (ex: carregamento lento, segurança). | Foca em intermediar acesso a um objeto, não em simplificar um grupo complexo de objetos. | | Composite (B) | Tratar objetos individuais e composições de objetos de forma uniforme. | Útil para estruturas hierárquicas (árvores), não para simplificar chamadas de subsistemas. | | Flyweight (C) | Compartilhar dados para reduzir consumo de memória. | Foco em otimização de recursos, não em arquitetura de acoplamento. | | Adapter (D) | Traduzir uma interface para outra compatível. | Resolve incompatibilidade de formatos, não a complexidade de múltiplas chamadas. | Conclusão O padrão Facade é a solução indicada para encapsular a complexidade de um subsistema, permitindo que clientes (como a interface do usuário) interajam com o sistema através de uma interface simples, resolvendo o problema de acoplamento e manutenção descrito no enunciado.

Explicação passo a passo

Análise da Questão

Por que a alternativa E é a correta?

Análise das outras alternativas

Conclusão

Mais questões de Engenharia

Tem outra questão de Engenharia?

Padrão	Função Principal	Por que não se aplica aqui?
Proxy (A)	Controlar o acesso a um objeto (ex: carregamento lento, segurança).	Foca em intermediar acesso a um objeto, não em simplificar um grupo complexo de objetos.
Composite (B)	Tratar objetos individuais e composições de objetos de forma uniforme.	Útil para estruturas hierárquicas (árvores), não para simplificar chamadas de subsistemas.
Flyweight (C)	Compartilhar dados para reduzir consumo de memória.	Foco em otimização de recursos, não em arquitetura de acoplamento.
Adapter (D)	Traduzir uma interface para outra compatível.	Resolve incompatibilidade de formatos, não a complexidade de múltiplas chamadas.