Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Design Patterns
Code

Padrões de projetos: Padrão Singleton

by
Difficulty:IntermediateLength:ShortLanguages:

Portuguese (Português) translation by Rafael Gadotti Bachovas (you can also view the original English article)

Neste artigo você vai aprender como implementar o padrão de projeto Singleton, o por que e quando utilizar esse padrão em suas aplicações. Como o nome 'Singleton" sugere, este método nos permite criar uma e somente um instância de um objeto.

Vamos ver o que o Wikipedia nos diz sobre este padrão de projeto:

O padrão Singleton garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto. Isso é útil quando exatamente um objeto é necessário para coordenar as ações em todo o sistema.

Como mencionado anteriormente, quando queremos ter certeza de que um, e somente um, objeto deva ser criado para qualquer classe, então devemos implementar o padrão Singleton para esta.

Você deve se perguntar o por que de implementar uma classe que nos permita criar apenas um objeto da mesma. Eu diria que há muitos cenários onde podemos aplicar este padrão de projeto. Isso incluí: classe de configuração, classe de sessão, classe de banco de dados, e muito mais.

Vou pegar um exemplo de classe de banco de dados para este artigo. Primeiro vamos ver que problema podemos ter caso o padrão Singleton não seja implementado nesta classe.

Problema

Imagine uma classe de conexão de banco de dados muito simples, que cria uma nova conexão sempre que um objeto dessa classe é criado.

No exemplo acima, você pode ver que uma conexão com o banco de dados será criada sempre que um objeto dessa classe for criado. Portanto, se um desenvolvedor criou um objeto desta classe em vários lugares da aplicação, imagine o número de conexões com o banco de dados (idênticas) que foram criadas.

Então, sem saber, o desenvolvedor está cometendo erros que levam a um enorme impacto no desempenho do banco de dados e no servidor do aplicativo. Vamos ver a mesma coisa através da criação de objetos diferentes daquela classe.

Se você ver a saída do código acima, você irá perceber que cada objeto tem um novo ID atribuído, então todos os objetos são uma referência nova, que aloca espaços diferentes da memória. Então, sem saber, a nossa aplicação vai usar recursos que não são realmente necessários.

Solução

Não está em nosso controle, como os desenvolvedores usam nossa estrutura base. É do nosso controle apenas quando o processo de revisão de código ocorre, mas durante o desenvolvimento, não podemos acompanhar o tempo todo.

Para previnir essa situação, devemos criar nossa classe base de tal forma que não permita a criação de vários objetos dessa classe, ao invés disso, retornaremos um objeto criado anteriormente, se houver. Este é o caso onde devemos considerar a utilização do padrão Singleton para as nossas classes base.

Ao implementar esse padrão, o nosso objetivo será o de permitir a criação de um objeto de uma classe uma e apenas uma vez. Permitam-me acrescentar o código da classe abaixo e, em seguida, vamos passar por cada parte desta.

Há pouca indicação que a classe acima é uma classe Singleton. A primeira coisa é um construtor do tipo private, o que impede a criação do objeto através da palavra-chave new. Outra indicação é uma variável estática que detém a referência a um objeto já criado.

Se você comparar a saída de ambas as seções, você vai ver na saída do padrão Singleton, que a identificação do objeto é a mesma para todos os objetos. Mas esse não é o caso quando este padrão não é utilizado.

Singleton é como um anti-padrão

Esse padrão de projetos é chamado também de anti-padrão pelas seguintes razões:

  1. Ele viola o princípio de responsabilidade única que diz que a classe é inteiramente responsável por suas ações desde sua criação até o fim do seu ciclo de vida.
  2. Ele introduz o estado global para sua aplicação. Eu diria que o estado global é ruim pois qualquer parte do código pode alterar seu valor. Então, no momento de analisar o código, fica difícil saber em qual momento foi obtido o valor atual da variável global.
  3. Singleton é geralmente uma má idéia se você está fazendo testes de unidade, e geralmente é uma má idéia não executar testes de unidade.

Conclusão

Eu fiz melhor para explicar o padrão Singleton, que é amplamente discutido na internet. Espero que você ache este artigo útil. Nós abordamos os dois aspectos desse padrão, o de um padrão de projetos e o de um anti-padrão.

Por favor, deixe seus comentários e/ou sugestões abaixo, irei responder o mais breve possível. Vocês podem me seguir no Twitter @XpertDevelopers ou me enviar um email.

Seja o primeiro a saber sobre novas traduções–siga @tutsplus_pt no Twitter!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.