Best practice on PHP singleton classes [duplicate]

Question

Possible Duplicate:
Who needs singletons?

I always write with respect to best practice, but I also want to understand why a given thing is a best practice.

I've read on in an article (I unfortunately don't remember) that singleton classes are prefered to be instantiated, rather than being made with static functions and accessed with the scope resolution operator (::). So if I have a class that contains all my tools to validate, in short:

class validate {     private function __construct(){}     public static function email($input){         return true;     } } 

I've been told this is considered bad practice (or at least warned against), because of such things as the garbage collector and maintenance. So what the critiques of the "singleton class as static methods" wants, is that I instantiate a class I'm 100% certain I will only ever instantiate once. To me it seems like doing "double work", because it's all ready there. What am I missing?

What's the view on the matter? Of course it's not a life and death issue, but one might as well do a thing the right way, if the option is there :)

Answer 1

An example singleton classes in php:
Creating the Singleton design pattern in PHP5 : Ans 1 :
Creating the Singleton design pattern in PHP5 : Ans 2 :

Singleton is considered "bad practice".

Mainly because of this: How is testing the registry pattern or singleton hard in PHP?

• why are singleton bad?

• why singletons are evil?

• A good approach: Dependency Injection

• Presentation on reusability: Decouple your PHP code for reusability

• Do you need a dependency injection container

• Static methods vs singletons choose neither

• The Clean Code Talks - "Global State and Singletons"

• Inversion of Control Containers and the Dependency Injection pattern

Wanna read more? :

• What are the disadvantages of using a PHP database class as a singleton?

• Database abstraction class design using PHP PDO

• Would singleton be a good design pattern for a microblogging site?

• Modifying a class to encapsulate instead of inherit

• How to access an object from another class?

• Testing Code That Uses Singletons

A Singleton decision diagram (source):

Answer 2

A singleton object is an object that is only instantiated once. That is not the same as the Singleton Pattern, which is a (Anti-) Pattern how to write a class that can be only instantiated once, the Singleton (large S at the beginning):

“Ensure a class has only one instance, and provide a global point of access to it.”

As far as PHP is concerned, you normally do not need to implement the Singleton Pattern. In fact you should avoid to do that when you ask for best practice, because it is bad practice.

Additionally most PHP code examples you find are half-ready implementations of the pattern that neglect how PHP works. These bogus implementations do not go conform with the "ensure" in the pattern.

This also tells something: Often that it is not needed. If a sloppy implementation does the work already while not even coming close to what the pattern is for, the wrong pattern has been used for the situation, it's starting to become an Anti-Pattern.

In PHP there normally is no need to ensure at all costs that a class has only one instance, PHP applications are not that complex that you would need that (e.g. there are no multiple threads which might need to refer to an atomic instance).

What is often left is the global access point to the class instance, which is for what most PHP developers (mis-) use the pattern. As it's known as-of today, using such "Singletons" lead to the standard problems of global static state that introduce complexity into your code across multiple levels and decrease re-usability. As a programmer you loose the ability to use your code in a flexible way. But flexbility is a very important technique to solve problems. And programmers are solving problems the whole day long.

So before applying a Design Pattern the pro and cons need to be evaluated. Just using some pattern most often is not helpful.

For starters I would say, just write your classes and take care how and when they are instantiated in some other part of your application logic so things are kept flexible.