Design Pattern: Singleton
Chegamos a nossa última semana nos Padrões Criacionais, mas muita calma nessa hora ainda restam 18 padrões para estudarmos (Estruturais e Comportamentais), portanto estamos ainda no começo de nossa jornada.
Vamos entender o que o GoF menciona sobre o Padrão Singleton.
Singleton Pattern — Definição do GoF
Certifique-se de que uma classe tenha apenas uma instância e forneça um ponto de acesso global a ela.
O Padrão Singleton é bem simples e bastante utilizado no dia a dia, apesar que ele também é chamado de anti-padrão (antipattern) e por este motivo seria o Patinho Feio dos padrões GoF e um dos motivos é por conta que fazem uso do Singleton como variável global, logo criando um forte acoplamento e realizando manutenção de estado.
Os profissionais mais puristas da Orientação Objeto não fazem uso do Singleton, justamente pelo motivo citado acima, porém não sejamos 8 e nem 80, analise o que seu negócio está necessitando e defina se o uso é válido, mas para isso vamos aprender o uso de mais este padrão? Então vem comigo!
Para começar, você sabe como podemos criar um objeto a partir de uma classe qualquer? Bem, se chamarmos nossa classe de ClasseQualquer, poderíamos utilizar a seguinte linha de código:
var objQualquer= new ClasseQualquer();
Analisando o código acima, notamos que se utilizarmos a palavra reservada new mais 20 vezes, teremos mais 20 objetos da ClasseQualquer, correto?
Isso pode ser uma criações desnecessárias de objetos, gerando uma preocupação, mediante que as chamadas do construtor estão ainda mais caras e por isso, precisamos restringi-los e neste caso o Singleton é muito útil, pois sua função é exatamente garantir que tenhamos apenas uma instância de determinado objeto.
Em resumo, saiba que seguindo o Padrão Singleton, criamos uma instância apenas se ela não estiver disponível, caso contrário utilizamos a instância existente para atender às nossas necessidades e neste momento você já deve ter imaginado que evitamos a preocupação citada acima sobre criações de objetos desnecessários.
O Diagrama UML para o Padrão Singleton, ficaria da seguinte forma?
Diferente de outros padrões que já estudamos até aqui, o Singleton não tem muitos objetos para serem explicados, veja que temos a classe Singleton com um campo privado chamado instance e neste será controlada a instância, temos um construtor privado e um método chamado getInstance que retornará a instância privada, normalmente a classe é selada (sealed) justamente para ninguém possa herdar a classe.
Implementação
Chegamos ao momento da prática e o motivo pelo qual o Padrão Singleton é muito simples enquanto diagrama de classes, não estarei colocando a imagem deste gerado pelo nosso projeto, apenas o que já foi citado acima.
Quanto a implementação, teremos alguns muitos exemplos e o motivo?Descobrirá já, já…
Observe que esta implementação é muito simplificada (até em demasia), funciona o Singleton? Sim, mas se atente no seguinte cenário e se o seu sistema for multithread? Esta solução não atenderá, ou seja, não é uma solução Thread Safe… realize você o teste, baixe o projeto do meu GitHub.
Double Check
Para isso temos uma outra forma de implementação, veja a seguir.
Em nosso Cliente (Program.cs) realizamos alguns ajustes na chamada para que ele realize a operação com mais de uma thread, certificando assim que a implementação de nosso Padrão Singleton atenderá a mais de uma thread.
Sealed
Ainda temos mais um problema em nossas implementações, observe que se não selarmos a classe Singleton, esta poderá ser herdada por outras classes e com isso instanciarmos uma classe herdada violando então o padrão e para resolver isso temos os seguintes ajustes:
Nosso Client (Program.cs) permanecerá da mesma maneira, porém fiz três ajustes:
- Alteração da Classe Singleton para sealed, justamente para evitar heranças.
- Propriedade estática e privada de instance, sendo readonly e com instanciação Eager Loading, ou seja, gerando instância no momento de iniciar o sistema.
- Ajuste para utilização de corpo da expressão para retorno de instance, não havendo necessidade de declaração do Get (recurso presente desde a versão 6 do C#).
Existe mais uma opção de implementação que seria através de inicialização lenta (Lazy Loading), utilizando a seguinte implementação:
Lazy consiste numa técnica na qual atrasamos a instanciação do objeto, ou seja, a criação é realizada somente quando for necessário e não ao inicializar a aplicação conforme o Eager Loading, utilize esta técnica sempre que a criação de seus objetos forem algo mais custoso.
Finalizando…
Ao fim de Outubro de 2019, Erich Gamma (GoF) respondeu em entrevista com Larry O´Brien o seguinte, segue abaixo.
Larry: Como você refatoraria “Design Patterns”?
Erich: Fizemos este exercício em 2005. Aqui estão algumas notas da nossa sessão. Descobrimos que os princípios de design orientado a objetos e a maioria dos padrões não mudaram desde então. Queríamos mudar a categorização, adicionar alguns novos membros e também eliminar alguns dos padrões. A maior parte da discussão foi sobre como mudar a categorização e, em particular, quais padrões devem ser descartados.
Ao discutir quais padrões descartar, descobrimos que ainda amamos todos eles. (Na verdade não — sou a favor de abandonar Singleton. Seu uso quase sempre é um Design Smell.)
Leia a entrevista na íntegra através deste link: https://www.informit.com/articles/article.aspx?p=1404056
Agradeço mais uma vez a você que vem acompanhando a série de Padrões de Projetos e que ficou até o final de mais um artigo, finalizamos a etapa Criacional dos Padrões de Projeto, na semana que vem teremos uma pequena pausa para montagem do material da próxima etapa, com isso iniciamos os Padrões Estruturais no dia 19 de Setembro de 2022 (segunda-feira), com Adapter.
Mais uma vez peço a você que curtiu este artigo para aplaudir aqui no Medium, compartilhar com seus amigos e colegas de profissão, será muito bem vindo e auxilia para que eu continue esse trabalho na comunidade. Obrigado!
Forte abraço e até a próxima…
