André está desenvolvendo um sistema com uso de EJBs, os objetos distribuídos da plataforma Java, e resolveu estudar a arquitetura adotada na plataforma JEE. Sua análise levou à conclusão de que a implementação do pool de Session Beans segue o padrão:
- A)Proxy;
Errada, porque Proxy controla o acesso a um objeto, mas nao explica o reaproveitamento de varias instancias em pool.
- B)Adapter;
Errada, porque Adapter serve para converter interfaces incompatíveis, e nao para compartilhar objetos ou reduzir custo de criacao.
- C)Flyweight;
Certa, porque o pool reutiliza instancias de Session Beans, ideia central do Flyweight, que busca compartilhamento para economizar recursos.
- D)Abstract Factory;
Errada, porque Abstract Factory cria familias de objetos, mas nao trata de pools nem de compartilhamento de instancias.
- E)Chain of Responsibility.
Errada, porque Chain of Responsibility organiza uma cadeia de tratamento de requisicoes, sem relacao com pool de beans.
Gabarito: C
Quando voce pensa em um pool de Session Beans, imagine uma gaveta com varios objetos prontos para uso, em vez de criar um novo a cada chamada. Isso economiza tempo e recursos, porque o sistema reaproveita instancias ja existentes quando possivel. Em plataformas JEE, essa ideia aparece muito na infraestrutura dos EJBs, especialmente para controlar desempenho e escalabilidade. O ponto central aqui é o compartilhamento inteligente de objetos semelhantes. O container pode manter instancias preparadas e entregar uma delas quando necessario, em vez de ficar fabricando beans sem parar. Essa lógica combina com o padrão Flyweight, que busca reduzir custo de criacao e memoria ao reutilizar objetos que podem ser compartilhados. Por isso o gabarito C está correto: o pool de Session Beans funciona como uma colecao de instancias reutilizaveis, permitindo que a plataforma atenue o peso de criar e destruir objetos o tempo todo. A ideia do Flyweight é exatamente essa, compartilhar o que for possivel e deixar apenas o estado externo variar conforme a necessidade. Em resumo: menos desperdicio, mais eficiencia, e o container feliz da vida. Se voce confundir com padroes de criacao ou de estrutura, a chance de errar cresce. Aqui a pista mais forte é o reaproveitamento de instancias em um ambiente distribuido e gerenciado pelo container, que é bem a cara do Flyweight.