Padrões Gerativos, Parte 2

4.1 Construtor

Builder é um padrão de design generativo que fornece uma maneira de criar um objeto composto.

Separa a construção de um objeto complexo de sua representação de forma que o mesmo processo de construção pode resultar em diferentes representações.

Forças:

• permite alterar a representação interna do produto;
• isola o código que implementa construção e apresentação;
• oferece um controle mais preciso sobre o processo de design.

Lados fracos:

• o algoritmo para criar um objeto complexo não deve depender de quais partes o objeto consiste e como elas se encaixam;
• o processo de construção deve fornecer diferentes representações do objeto que está sendo construído.

Um bom exemplo é a classe HttpRequest, que tem uma subclasse HttpRequest.Builder que pode ser usada para criar instâncias da classe HttpRequest e garantir que sejam válidas.

4.2 Inicialização preguiçosa

A inicialização preguiçosa é uma técnica de programação quando alguma operação de uso intensivo de recursos (criação de objeto, cálculo de valor) é executada imediatamente antes de seu resultado ser usado.

Assim, a inicialização é realizada “sob demanda” e não antecipadamente. Uma ideia semelhante encontra aplicação em várias áreas: por exemplo, compilação on-the-fly e o conceito de logística Just-in-Time.

Um caso especial de inicialização preguiçosa - criar um objeto no momento de acessá-lo - é um dos padrões de projeto generativos. É normalmente usado em conjunto com padrões como Factory Method, Loner e Proxy.

Forças:

• A inicialização é realizada somente quando é realmente necessária;
• A inicialização inicial do aplicativo é acelerada: tudo o que pode ser adiado é adiado.

Lados fracos:

• Não é possível definir explicitamente a ordem na qual os objetos são inicializados;
• Há um atraso no primeiro acesso ao objeto, o que pode ser crítico quando outra operação intensiva em recursos é executada em paralelo. Por causa disso, é necessário considerar cuidadosamente a adequação do uso da inicialização preguiçosa em sistemas de software multithread.

Lembra-se de como, ao escrever web.xml, você pode especificar a ordem de início dos servlets? Este é exatamente o resultado do carregamento lento. O Tomcat criará objetos servlet na primeira vez em que forem acessados.

4.3 Conjunto de objetos

Um pool de objetos é um padrão de projeto pai, um conjunto de objetos inicializados e prontos para uso. Quando o sistema precisa de um objeto, ele não é criado, mas retirado do pool. Quando um objeto não é mais necessário, ele não é destruído, mas devolvido ao pool.

O pool de objetos é usado para melhorar o desempenho quando criar um objeto no início de um trabalho e destruí-lo no final é caro. A melhoria de desempenho é especialmente perceptível quando os objetos são criados e destruídos com frequência, mas apenas um pequeno número deles existe ao mesmo tempo.

Um pool de objetos é útil quando um objeto possui outros recursos além da memória, como soquetes de rede. Ou se a coleção de objetos ocupa uma parte significativa da memória do computador e muito "lixo" é criado.

Como você deve se lembrar, o Tomcat executa cada solicitação em um thread separado. Mas os threads não são criados novamente a cada vez, mas são armazenados no pool de threads. Isso permite uma execução mais rápida de solicitações: quando um thread é necessário, ele é simplesmente retirado do pool. A propósito, a questão é: como você colocaria o thread em execução no pool e o retiraria do pool?