No postagem anterior dei uma visão geral sobre os tipos de Padrões de Projetos, Padrões de Criação (Creational Patterns), Padrões Estruturais (Structural Patterns), Padrões Comportamentais (Behavioral Patterns), caso queira ler a postagem só clicar no link - Introdução aos tipos de padrões de projetos.
Agora iremos falar sobre o famigerado Singleton, o padrão mais citado em entrevistas de empregos por desenvolvedores, quando questionados sobre padrões de projetos.
O padrão Singleton resolve dois problemas:
-
Garante que classe que implementa esse padrão terá apenas uma instancia. Isso permite que o acesso ao um recurso que é compartilhado ou custoso de ser construído, do ponto de vista computacional, seja criado apenas uma vez. Como exemplos temos: criação de conexão com o banco de dados, carregar dados do sistema de arquivos, etc.
-
Disponibilizar um ponto de acesso global para a instância. Isso quer dizer que a solução instanciada poderá ser aproveita pelo o restante da aplicação sem a necessidade de novas instâncias. A ideia é semelhante ao uso de variáveis globais, mas sem o efeito negativo de alteração de valores ao longo do fluxo de execução, Singleton protege desse comportamento indesejável.
O uso desse padrão é aplicável nos casos onde é desejável que exista uma única instância para todos os clientes ou quando precisa ter controle sobre variáveis globais.
Diagrama
Vantagens
-
Há certeza que existirá apenas uma instância da objeto.
-
Ponto de acesso global para a instância.
-
Lazy Initialization, o objeto é inicializado apenas quando é requisitado, na primeira vez.
Desvantagens
-
O padrão poder mascarar um design ruim, por exemplo, quando componentes da aplicação conhecem muito entre si.
-
Se for inocentemente implementado pode acarretar em problemas de concorrência em ambientes multithread. O ideal é garantir que o objeto seja imutável.
-
Pode ser difícil escrever teste unitários para esse tipo de implementação, por conta de restrições dos frameworks de testes e mocks.