Por definição, o padrão Singleton serve para garantir que exista apenas uma instância de determinada classe e mantendo um ponto global de acesso à essa instância. Por exemplo, eu desejo que na minha aplicação exista uma entidade responsável por gerar logs, e ela precisa ser única pois acessos concorrentes a um arquivo podem ser desastrosos, ou eu tenho limitações de recurso e preciso de uma entidade única que gerencie uma conexão socket ou com um banco de dados. E para isso foi formalizado o padrão Singleton.

Para garantir que só existe uma instância daquela classe eu preciso me preocupar em tratar a criação desse objeto, ou seja, limitar essa criação fazendo com que o sistema antes de criar, cheque se já existe uma instância, caso positivo retorna essa instância, caso contrário cria uma nova. Para isso, eu preciso fazer com que meu construtor seja *privado*, sendo assim acessado só por métodos da mesma classe, e prover um método de classe (estático) que possa checar a existência prévia da instância. Em PHP a implementação seria assim:

<?class XPTO {private static $instance;private $estado; //Usaremos esse campo mais na frente

public static function getInstance() { if(empty(self::$instance)) {     self::$instance = new XPTO(); } return self::$instance;}

private function __construct() { $this->setEstado("Inicial"); }

public function getEstado() { return $this->estado;}

public function setEstado($novoEstado) { $this->estado = $novoEstado;}}?>

Sendo assim, eu não posso, de fora da classe, instanciar um novo objeto do tipo XPTO, mas tenho que chamar o metodo getInstance para pegar a instancia única dessa classe.

Até aqui tudo parece muito bonito, mas aí esbarramos numa limitação do PHP nesse sentido: Em PHP não existe o conceito de Aplicação, ou seja, cada vez que alguem acessa sua página, o que acontece é apenas a execução de um script numa thread do seu webserver, e mesmo que várias pessoas acessam simultaneamente o *mesmo* script, essas execuções são independentes, não há relação nenhuma entre elas. E como não existe o conceito de aplicação, os objetos e variáveis só permanecem na memória no curto tempo da execução do script, quando o PHP processa o script e devolve ao webserver para ser enviado para o visitante, aqueles valores utilizados são limpados da memória.

Seguindo esse raciocínio chegamos a conclusão de que em PHP o padrão Singleton é útil para organizar as idéias do programador e deixar o código melhor organizado evitando variáveis globais, porém não provê todas as funcionalidades que se espera dele, e para demonstrar essa conclusão executarei o seguinte teste:

1 – Crio o arquivo teste.php.

2 – Nesse arquivo importo a classe XPTO criada anteriormente:

<? require("Xpto.class.php"); ?>

3 – Pego a instância única da classe XPTO e checo qual o estado atual dele:

<?$xpto = XPTO::getInstance();print("Estado atual do objeto XPTO: " . $xpto->getEstado());?>

4 – Pego novamente a instância, altero esse estado e checo novamente:

<?$xpto = XPTO::getInstance();$xpto->setEstado("Alterado");print("<br/>Estado atual do objeto XPTO (depois de alterado): "  . $xpto->getEstado());?>

Quando esse script for executado, pela primeira vez, a saída será:

Estado atual do objeto XPTO: InicialEstado atual do objeto XPTO (depois de alterado): Alterado

Se houvesse o conceito de aplicação, esse objeto persistiria na memória e na próxima execução a saída *seria*:

Estado atual do objeto XPTO: AlteradoEstado atual do objeto XPTO (depois de alterado): Alterado

Mas quando o PHP terminou de processar a primeira execução, ele removeu tal objeto da memória e na segunda execução ele foi recriado do zero, voltando ao estado inicial e tendo a saída idêntica à primeira execução.

Estado atual do objeto XPTO: InicialEstado atual do objeto XPTO (depois de alterado): Alterado

Existem outras maneiras de se testar isso, mas essa foi a maneira que achei mais simples.

E esses foram meus dois centavos para mostrar que o Singleton em PHP nem sempre funciona como pensamos.

Design Patterns: Elements of Reusable Object-Oriented Software

O famoso “Gang of Four” (pois foi escrito por 4 caras, dã). Esse livro foi escrito nos anos 90 (94 se não me engano) tendo como principal autor o Erich Gamma, teve como objetivo formalizar soluções para problemas recorrentes no desenvolvimento de software de forma que o código ficasse mais limpo, melhor estruturado e reaproveitável, essas soluções ficaram conhecidas como Design Patterns (Padrões de Projeto) e esse livro se tornou uma bíblia no meio dos desenvolvedores. Os exemplos são dados em C++ e Smalltalk, mas os conceitos servem para qualquer linguagem OO. É leitura obrigatória pra quem quer escrever bons códigos. (Existe uma versão traduzida, mas algo me diz que essas traduções são pobres, por isso prefiro o original)
(ISBN: 0201633612)

P.S.: Tem um livro novo sobre Design Patterns da série Head First (em português, Use a Cabeça!) que parece ser bacana também. Os livros dessa série são bem interessantes e tratam dos assuntos técnicos de maneira bem descontraída, o livro até parece até um gibizão (ISBN: 0596007124) (Existe versão em português)

E minha segunda dica (na realidade, a terceira) é:

PHP 5 Objects, Patterns, and Practice

Esse é um que trata de como se programar BEM em PHP, que é por muitos tida como uma linguagem de difícil manutenção (coisa que depende do programador, e PHP ficou com essa fama por ser fácil e muita gente sem boas noções de programação faz seus sisteminhas nela com códigos sebosos, bugados e fedorentos mal escritos ).
Ele mostra como funciona a Orientação a Objeto no PHP5 (que foi um grande avanço em relação ao 4) , mostra também aplicações de Design Patterns em PHP e boas práticas de programação. Ótimo livro!
(ISBN: 1590593804) (Não existe versão em português)

Ah, e comprar essas coisas na Amazon muitas vezes vale a pena, as vezes sai mais barato e até chega antes do que comprar em lojas nacionais (Porque elas vão importar e têm que juntar uma quantidade X pra fazer pedido e blá blá blá).