Além disso, analisaremos como estes padrões são empregados em recursos da plataforma Java EE, o que reforça ainda mais nossos conhecimentos para a importante decisão de quando adotá-los em nossos projetos.
O que seria de nós se não existissem os padrões? A reflexão acerca deste questionamento pode parecer sem nexo, contudo, refletir sobre os benefícios da padronização vem ao encontro com o assunto abordado neste artigo, quase que em sua totalidade.
A fim de estimular o estudo sobre padrões, podemos utilizar um exemplo: imagine se as posições das letras dos teclados de computadores variassem de acordo com cada fabricante?
Para o usuário seria muito ruim, pois ele teria que se adaptar aos vários tipos de teclados, tornando tarefas simples extremamente ineficientes, como digitar este artigo, por exemplo.
Assim como os padrões são fundamentais em diversas áreas, não poderia ser diferente na Engenharia de Software.
Nesta área, podemos, por exemplo, documentar um software de várias maneiras, seja através de um documento de texto, um desenho em uma folha de papel ou até mesmo em uma planilha.
No entanto, quando utilizamos um padrão, como a Unified Modeling Language (UML), propiciamos uma compreensão mais clara e objetiva da documentação gerada.
Assim como a UML para a documentação, no desenvolvimento de software a adoção de padrões favorece a criação de um código-fonte melhor no que diz respeito à compreensão, além de colaborar para a manutenção e a evolução do projeto.
Com o propósito de alcançarmos esses benefícios e apoiar o desenvolvedor na resolução de problemas comuns, como o acesso a diversas fontes de dados, a localização de um serviço, a mediação entre o formulário e a classe controladora, a auditoria das ações do usuário, o mecanismo de autenticação e autorização, entre outros, existem técnicas que visam facilitar o desenvolvimento de forma padronizada, conhecidas como Design Patterns.
Baseando-se em problemas comuns, quatro autores criaram vinte e três soluções padronizadas, catalogando-as no livro Design Patterns: Elements of reusable object-oriented software.
Este livro tornou-se referência mundial quando o assunto é a resolução de problemas específicos em projetos de software orientados a objetos, independente da linguagem utilizada.
Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, mais conhecidos como a Gangue dos Quatro (Gang of Four - GoF), dividiram seus respectivos padrões em três categorias: Padrões de Criação, Estruturais e Comportamentais.
Com base nas experiências destes autores, será apresentada neste artigo uma visão pragmática acerca da utilização dos Design Patterns Singleton e Flyweight, com exemplos reais aplicados nas plataformas Java Standard Edition e Enterprise Edition.
Introdução ao Singleton
Você já implementou alguma classe responsável por armazenar e gerenciar um cache de quaisquer dados e se deparou com a necessidade de compartilhar uma única instância desta por toda a aplicação?
Sabemos que, ao utilizar a palavra reservada new, um novo objeto é criado e mantido em memória até que não existam mais referências ao mesmo, tornando-o passível de descarte pelo Garbage Collector.
Na maioria dos casos é comum a criação de diversos objetos de uma mesma classe, mas existem cenários em que podemos gerar, manter e compartilhar um único objeto.
É neste momento que podemos nos beneficiar de um dos padrões mais conhecidos e de fácil compreensão pelos desenvolvedores, o Singleton. Criado pela Gangue dos Quatro, este design pattern faz parte da categoria dos padrões de criação e seu nome é oriundo do jogo de baralho Singleton, mais especificamente quando resta apenas uma carta na mão.
O Singleton tem como objetivos:
- Garantir a existência de uma única instância da classe relacionada no sistema;
- Disponibilizar um ponto de acesso central a essa instância.
Ao garantir uma única instância de uma classe, podemos evitar situações indesejáveis, como o alto consumo de memória quando precisamos de um mesmo objeto repetidas vezes. Por
exemplo, ...
