Engenharia Múltipla Escolha

Um colega seu está implementando uma 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 da 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 revisar a versão feita pelo seu colega, qual padrão você recomendaria?

Um colega seu está implementando uma 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 da 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 revisar a versão feita pelo seu colega, qual padrão você recomendaria?

  1. Proxy
  2. Composite
  3. Flyweight
  4. Adapter
  5. Facade

Resolução completa

Explicação passo a passo

E
Alternativa E

Alternativa E - Facade

O cenário descrito na questão aponta para um problema clássico de acoplamento excessivo entre camadas de software (Interface do Usuário vs. Lógica de Negócio). O colega está fazendo muitas chamadas diretas a objetos internos, tornando o sistema complexo e difícil de manter, além de gerar código repetido (copy-paste).

A solução ideal é introduzir uma camada intermediária que simplifique essa interação. Isso permite que a interface do usuário converse com um único ponto de entrada, em vez de gerenciar dezenas de objetos diretamente.

Análise

O padrão de projeto que resolve exatamente esse problema é o Facade:

  • Definição: O padrão Facade fornece uma interface simplificada para um conjunto de interfaces em um subsistema. Ele define uma interface de alto nível que torna o subsistema mais fácil de usar.
  • Aplicação ao caso: Ao criar um Facade, o colega encapsularia a lógica complexa de chamar vários objetos de negócio em métodos simples.
  • Benefícios:
  • Redução de Acoplamento: A interface do usuário não depende mais da estrutura interna dos objetos de negócio.
  • Manutenibilidade: Se a lógica de negócio mudar, apenas o Facade precisa ser atualizado, evitando a necessidade de corrigir múltiplos módulos de interface.
  • Eliminação de Duplicação: O segundo módulo pode reutilizar o mesmo Facade, resolvendo o problema do "copiar e colar".

Por que as outras alternativas não se encaixam:

PadrãoFunção PrincipalPor que não é a resposta
ProxyControla o acesso a um objeto (ex: carregamento preguiçoso)Foca em controle de acesso, não em simplificar subsistemas complexos.
CompositeCompor objetos em estruturas de árvoreUsado para hierarquias (ex: menus de UI), não para abstração de serviços.
FlyweightCompartilhamento de estado para economia de memóriaFocado em performance e redução de uso de RAM, não em arquitetura de interfaces.
AdapterConverte interfaces incompatíveisUsado para fazer classes trabalharem juntas apesar de assinaturas diferentes, não para ocultar complexidade.

Em resumo, a necessidade explícita de uma "interface de mais alto nível disponível que encapsule esta complexidade" é a assinatura textual do padrão Facade.

Alternativa 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.