Os padrões de projeto fornecem soluções para problemas recorrentes no desenvolvimento de sistemas. Maria está desenvolvendo o sistema ComprasWeb e precisa resolver um problema comum de sistemas Web que é a recepção assíncrona de dados, onde deve ocorrer a atualização dos dados na interface do usuário quando ocorre a resposta do servidor, sem que haja o bloqueio das demais funções da interface. Para tratar o problema do ComprasWeb, Maria deve usar o padrão de projeto:
- A)Observer;
Correta: o Observer trata da notificação automática de dependentes quando ocorre uma mudança de estado, exatamente o que acontece na atualização assíncrona da interface.
- B)Chain of Responsibility;
Errada: Chain of Responsibility serve para passar uma solicitação por uma cadeia de objetos, não para sincronizar atualização de interface com resposta do servidor.
- C)Flyweight;
Errada: Flyweight é usado para compartilhar objetos e economizar memória, não para comunicação assíncrona ou atualização de tela.
- D)Data Access Object;
Errada: Data Access Object organiza o acesso a dados e persistência, mas não resolve o mecanismo de notificação da interface.
- E)Builder.
Errada: Builder é voltado para construção passo a passo de objetos complexos, sem relação com eventos ou atualização assíncrona.
Gabarito: A
Quando um sistema Web precisa receber dados de forma assíncrona e, ao mesmo tempo, atualizar a interface sem travar o resto da aplicação, a ideia central é avisar quem está interessado sempre que algo muda. É exatamente aí que entra o padrão Observer: um objeto "observado" muda de estado e notifica automaticamente os observadores cadastrados. Assim, a tela pode reagir à resposta do servidor sem bloquear as demais funções da interface. Pense no cenário como uma central de avisos: o servidor responde, o sistema dispara a notificação e a interface se atualiza sozinha. Isso é bem comum em aplicações com eventos, atualização de tela, notificações e integrações em tempo real. O padrão resolve a dependência entre quem gera a informação e quem precisa dela, deixando a comunicação mais organizada. Por isso o gabarito é a alternativa A. Em termos doutrinários, o Observer é um dos padrões clássicos do catálogo GoF e é justamente o mais associado ao mecanismo de publicação e assinatura, em que mudanças em um objeto são propagadas para vários interessados. Não há aqui uma regra legal específica, porque estamos no campo de engenharia de software e padrões de projeto. As outras alternativas fogem do problema: algumas tratam de construção de objetos, outras de acesso a dados ou de encadeamento de responsabilidades. O ponto-chave da questão é a atualização automática da interface quando chega a resposta assíncrona, sem bloqueio da tela. Isso é cara de Observer, sem maquiagem.