Usando o Padrão Singleton - Revista ClubeDelphi 133

Singleton é um padrão de projeto bastante conhecido da GOF (Gang of Four) onde uma classe pode ter apenas uma instância. Ele tenta garantir que a classe seja instanciada uma única vez e fornece um ponto de acesso global a ela.

Alguns componentes geralmente modelados como singletons são: camadas de acesso a dados, serviços de comunicação, como envio de e-mails, o objeto de configuração do sistema como um todo e toda e qualquer informação que tenha uma fonte única e que deva ser compartilhada por todas as outras classes.

Especialmente se uma classe de serviço ou de sistema é muito grande e custosa para se instanciar o uso de singleton faz com que durante toda a execução do sistema a classe seja instanciada uma única vez.

Classes que usam recursos escassos e / ou que não podem ser compartilhados, por exemplo, no caso de leitura e escrita em um arquivo de texto, apenas uma instância da classe teria acesso para leitura e escrita por vez. Outras tentativas de abrir um mesmo arquivo para leitura e escrita resultariam em um deadlock.

O uso de singletons deve ser justificado, visto que recentemente muitos têm considerado o singleton um anti-pattern. Afinal muitos dos problemas que alguns programadores costumam resolver usando singletons são possivelmente solucionáveis com injeção de dependência.

Singletons não devem ser usados como variáveis globais, mas sim como objetos que mantêm um estado comum e público a todas as classes do sistema. É o tipo de padrão de projeto que, na dúvida, é melhor não usar. Ele não deve ser usado como uma “variável global orientada a objeto”, nunca.

Nota: Se o singleton possui apenas métodos, mas não atributos, muitas pessoas implementam o singleton como uma classe com vários métodos de classe. Isso não é recomendável, pois viola vários princípios da orientação a objeto (regras de negócio espalhadas que não fazem parte de nenhuma classe). E mesmo que a classe não precise ser instanciada, ela ainda pode ser, embora neste caso não faça muita diferença. Você pode ter várias classes dependendo do seu singleton, mas é imprescindível que o singleton não dependa de nenhuma outra classe, pois isso causaria uma bagunça muito difícil de se consertar.

É realmente muito raro singletons serem necessários, mas tenho visto muitos membros da comunidade implementar singletons onde ele não é estritamente necessário, e o pior, implementar de maneira errada. Em alguns casos a implementação errada não causa nenhum impacto no sistema, mas em muitos casos elas podem causar erros de Access violation e memory leaks.

Para explicar o porquê disso, deve-se raciocinar: se os singletons não devem ser criados, eles também não devem ser destruídos, pois uma vez destruídos quem os recriará? E pior: as referências a ele (variáveis que o contém/apontam para ele) passam a ser inválidas no momento em que ele é destruído. Inválidas, porém diferentes de nil. Criar um singleton que já tem uma instância também é problemático. Depois que a segunda instância é criada e atribuída ao objeto global a referência ao objeto anterior é perdida. Sem referência, como o objeto será destruído? Causa-se assim um memory leak.

Um singleton também não deveria ser atribuível a outras variáveis ou passado como parâmetro para um método, pois não dá para garantir muito o que se fará de errado com ele.

Na seção de links desse artigo encontra-se uma série de URLs de blogs e fóruns discutindo sobre o uso de singletons e porque eles são considerados um anti-pattern.

Note que o que está sendo questionado é o uso indiscriminado do singleton como variável global. Para programadores que estão saindo de ambientes procedurais ou orientados a eventos e tendo suas primeiras incursões na programação OO pura os singletons podem parecer uma atraente alternativa às variáveis públicas globais.

Os leitores deste artigo poderão se perguntar: “mas para que fazer um artigo sobre esse assunto se não há consenso com relação aos seus benefícios?”. A resposta é simples, independente do uso correto do singleton saber como criá-lo é um conhecimento interessante para habitar a “caixa de ferramentas” de qualquer programador, mas o mais interessante é que o modo de se criar tal padrão pode mostrar detalhes interessantes do próprio Delphi. "