Some commenters seem averse to passing references to classes as function arguments. This could be for a few reasons: a) they don’t understand call by reference, b) their functions already have a prohibitive number of arguments, c) they’re code base is highly dependent on their usage of singletons.

One can argue that some people have never seen a project with 400.000 lines or larger. Trust me on this one, passing references as function arguments is inefficient. You are constantly moving the DB connection as a reference from one function to another, to another, to another. Is that bad? No. Is it nice coding? No. Code what you need, where you need it.

If you need the ref in function Z, but function Z is located at X -> Y -> Z, your wasting time, and code overview with these constant reference passing. Sure, a registry ref solves that problem if you need to deal with several dbi, param etc, but essentially, your doing the same thing over & over again. Again, code things where you need it. Its a wast of code space, to constantly pass references when you don’t need them, but you “might” need them later on. O wait, function Y did not need the ref, now we need to update function Y, and everywhere function Y is called to include it. Or, your like i said before, forced to constantly keep pasting the reference with all your function, even when they are not needed.

This discussion to me looks like almost all the MVC discussions i have read. No, thats not real MVC, this is. No, thats wrong, this is. No, your all wrong, that is. *grumbles*

One of the recurring arguments is: But we need to manage multi different database connections bla bla bla … No you don’t. Is it so hard to create a singleton for mysql, and one of oracle? Or equip your singleton to deal with multi connection types. There are lots of examples out there on the net ( some bad, some excellent ).

It looks like people are going overboard in a rabbit war, over no good reason. Sure, global declarations are something to be avoided if possible, but lets face it. If you need your Database connection at Z, you are not going to wast time, reconnection the connection every! time. So, you initial the DB connection as a singleton, or use a reference, or use a global ( a ref registry is the same as a ref dbi, no mather how you dress it up ). Thats it. The singleton in my eyes, saves code that you don’t need to write again, again. A proper implementation of a singleton prevents it from getting altered in a improper way.

Don’t underestimate the mess that can be created with a passing a ref all over the place. Seen it before. The arguments that can be used to put down a singleton, can in a lot of cases also be used against the other methods.

KISS people, KISS. The proper tool for the job. Unless there is a specific performance, bugs, or other problematic things around them, there is no reason to avoid singleton usage. A good implemented singleton is a good solution. All the rest is just people wanting to push there definition of “good” programming on each other. Just like almost any MVC thread where everybody has there own definition of “good” MVC.

Predictability/Hard Coupling:
These two issues are closely related. It is difficult to measure just how dependent (in this case, highly) on piece of code is to another when inputs aren’t explicitly being passed around. A function is deterministic insofar as given the same set of inputs it will return a single output. Unknowingly outputting or modifying the state of a foreign object is a side-effect. Given a singleton, it is impossible to say a function/method is deterministic. This is the case for two reasons: i) given that the singleton is not explicitly passed to the function, for any number of function calls there is no measure to show that the singleton’s state hasn’t changed, and given code dependent on the state of the singleton, the function’s return will be different, ie: not deterministic; ii) the function might modify the state of the singleton, the altering the rest of the program in an unpredictable way.

Garbage Collection
Although PHP runs as distinct processes, this is still applicable and definitely generalizable to other languages. When does a singleton object get garbage collected? In the case of PHP, it is likely collected when the current process is terminated because it never loses scope–regardless of if it used in the program or not. In essence, this is a memory leak.

Inheritance
If the singleton is implemented by using a class (eg: a registry), then extending the singleton class is a pain. Given a purposeful singleton class, extending it and using both the parent and child subclasses causes unwanted overlap with the static members. Obviously, this is an avoidable problem that leads to another unfortunate problem: boilerplate code because each singleton class needs to be separate.

This should be an indication to anyone using singletons that they are doing something wrong. In general, using singletons with classes is a hack to make object-oriented code more procedural. Boilerplate code is a signal to refactor code.

Final Thoughts
The general pattern I see is that for new programmers, the singleton appears to be a panacea. Unfortunately, the benefits of singletons are more apparent than real. At first, their conveniences seem amazing. However, as code bases grow, singletons have the effect of making code less maintainable. Their intended use–to have one and only one instance of a particular class–can be factored out into other solutions. Some commenters seem averse to passing references to classes as function arguments. This could be for a few reasons: a) they don’t understand call by reference, b) their functions already have a prohibitive number of arguments, c) they’re code base is highly dependent on their usage of singletons. Besides the last one, these problems are trivial. So why ought one pass objects by reference as inputs to places where they are used? One of the strongest points is that the code becomes implementation independent. The second you use a singleton, you are locked into the same instance of the same class. As kyberfabrikken exampled with database connections, by passing dependencies as arguments to functions, you are not limited to only one resource, and the same is generalized to one implementation. If this doesn’t seem important then please take a minute to think about it as the implication is important with respect to modularity and maintainability.

“If class A has a dependency on class S injected, then there is a strong coupling between A and S.”

“If class A has class S passed into a method, then there is a strong coupling between A and S.”

In all cases, if class A calls method S.Foo(), then there is a compile time dependency from A to S. Note that in all three cases the actual instance of S used can vary (including a subclass).

The primary difference between passing as an argument, dependency injection and singleton is how easy it is to change *when* the instance of S used is changed.

- For a method argument it is easy to use a different S each time. (You can use the same S each time if you want).

- For dependency injection it is easiest to set the instance of S once when A is created; if you want to use the same S this is easier than passing an extra parameter each time. (Note that you *could* change the instance of S held by A before each call, but it’s not as easy as if passed via a method.)

- For singleton it is easiest to set the instance of S once for the whole program. (Note you can still change that instance before each call).

Another consideration when ‘changing’ the instance of S is threading. If there are multiple threads potentially accessing the singleton (or class A’s injected S), then you would need to lock to isolate the different S’s. (Passing in as a method argument does not need the lock).

Note the same things can be done with all designs, just the ease of doing them differs. If you need a different instance of S each time, have multithreading issues, and have S readily available, it does not make sense to use a singleton and have to lock it each time (in fact, it’s stupid).

On the other hand, if you only have one S, the same S used by all, and it has no state that is going to screw up threads, then a singleton is easier than an additional argument passed through all layers of your methods.

One other aspect of the static binding that does differ between the methods is how obvious the static binding is: a method clearing has a paramter S; dependency injection has parameter S on the constructor (or a property of type S); use of a a singleton, however, is not visible in the public interface. (Many other solutions, such as extracting from a generic registry, also don’t explicitly have S in the public interface).

Remember, in all these cases, that the Singleton pattern does not prevent you having multiple instances (e.g. one per thread) or varying instances (the singleton can be any subclass of S). These are actually two of the benefits of the pattern from the original Design Patterns book (consequences 3. Permits refinement and 4. Permits variable number of instances).

In fact, the ability to use a subclass is one of the primary reasons in Design Patterns for using the Singleton pattern: “Use the Singleton pattern when … instance should be extensible by subclassing and should be able to use an extended instance without modifying their code.”

From the point of view of unit testing, this is brilliant: the target code uses the singleton to provide services/functions, and all your test code needs to do is configure the singleton instance with a stub implementation (e.g. mock).

A final note: using a registry to hold a collection of instances is one of the implementation issues actually discussed in Design Patterns as a “flexible approach”. In Patterns of Enterprise Application Architecture, Fowler further expands on the Registry pattern, as a particular implementation of Singleton.

Sly Gryphon

In our project we are already at a point where I would like to have “dynamic inheritance”.

Our pages are implemented as classes deriving from a MyProjectDefaultPage class for the unified layout. Quite a nice thing, because this allows a huge number of extension points. For instance, for the top menu, we can simply reimplement the “getTopmenuActiveItem” and return the name of the active menu item. And “getSubmenuItems” to return a formal list of items to show up in the submenu. Then we can make one more layer of subclasses that all share this submenu, but have different implementations of “getSubmenuActiveItem”.

(I hope this was understandable)

Now we might get at a point where we want to introduce skins. For this we would want to replace or extend the MyProjectDefaultPage with something else.

Ideally something like this:

$active_skin = ‘AlternativeSkin’;

AlternativeSkin::SomeSpecificPage extends DefaultSkin::SomeSpecificPage

SomeSpecificPage extends $active_skin::DefaultPage

$active_skin::DefaultPage extends DefaultSkin::DefaultPage

—

This time it’s not about singletons, but still about static symbols that we want to be dynamic.

The problem with encapsulating code in classes is that everything is locked up in separate components: how to get all the bits talking to each other? Who gets a reference to what is the basic problem of OOP design. Simply making things global to get around that is a bit of a cop out. Instead you should figure out how to pass objects around where they are needed.

Factories, a registry, or a dependency injection container can manage lifecycle if you genuinely want a single instance. Object assembly is really a layer all of its own. Good things happen when you pull that out from the rest of the code ;)

The benefit I see in static class methods (eventually with private static variables that behave like singletons) in bootstrapping is encapsulation. We can have private methods that load a bunch of ini files, etc. Better than having all that in spaghetti. And, we don’t have to say “load setting X” and later “use setting X” - we can just say MySetup::getX(), and the setup class will load the things if-not-done-yet.

Even better: Assume that we usually write some defaults into the $_SESSION when it’s empty, and eventually allow the user to switch these values. With a singleton or static methods, we can encapsulate all that: “MySettingX::get()” will look if the session value is already set, and if not fill it with defaults.

(I apologize for that much long-winded detail and eventually going off-topic, but without that it will be hard to see how the concepts apply to reality.)

The other benefit is that a single monolithic registry is the first step towards a finer grained collection of registries. You can fairly easy refactor towards having a number of registries. Eventually these registries might be possible to turn into actual objects.

Are we talking about different registries that have to be passed one-by-one? Like

or

or

As I understand, these are all different ways of dependency injection. What they have in common is that we either have to know which information the component will need, or that we have to generously inject everything.

Now, let’s have a look at an example.
Some things that our view classes (or even the templates) will need:
- information about the user and the session: Does he have admin rights? In which language is he surfing? Depending on these things, some layout elements might not be displayed, or displayed in a different way.
- shared layout elements (let’s call them widgets) like menu, calendar, advanced time display (’this was posted * minutes ago’), avatar pictures etc.
- Some of these shared layout elements might again need information about the user, the environment etc, or might even need an own database connection (the calendar for instance, to look into the calendar database).
- In the current design there is a ‘page’ object where different layout components are buffered, to be finally assembled in a centralized place (page.php). I don’t like the specific way we do it, but I’m also not going to change it that soon.

Typically, our controller will not know which of these things are needed in the view classes (except for the page object, which is needed in any case) - a designer might choose, out of the blue, to use a calendar or other layout elements, or to add some power controls that require admin rights.

With dependency injection or registry we would have to pass around a ‘widget factory’, a ‘user’ object etc, all injected one-by-one with setters or constructor parameters, or stuffed into a passed-around registry. And the widget factory for itself would also need to know how to get information about the user and the database, and pass that information to those widgets which need it. (another question is, how MVC can be applied to autonomous layout widgets)

Currently we do much of the above with singletons and static functions. Maybe at the cost of flexibility, but so far we have not really missed it - most of all because we did not try anything that requires flexibility. What we win is transparency - which means, you always know where a function is implemented.

However, there is a big difference between not redefining defaults and actively introducing them. What I’m advocating, is that userland code should refrain from introducing new static symbols.

Ok with that. Maybe the ‘+’ example was a bit exaggerated anyway.

Some static symbols in PHP are the $_SESSION, $_GET and other global variables. Maybe the ideal way would be to hide these things in objects. But, it does already help to hide these things behind static class methods - if only for making it easier to prevent arbitrary write access.

Another typical example for static symbols is a class constructor, or a static factory method. If we don’t want static symbols to be used globally, we have to take care that a explicit constructors (as any static symbols, including singletons and static factory methods) are only used in the “bootstrapper” (where the hell does this word come from) and inside the component they belong to.

I would say that you could equally well write the bootstrapping without singletons, as you can with.

The benefit I see in static class methods (eventually with private static variables that behave like singletons) in bootstrapping is encapsulation. We can have private methods that load a bunch of ini files, etc. Better than having all that in spaghetti. And, we don’t have to say “load setting X” and later “use setting X” - we can just say MySetup::getX(), and the setup class will load the things if-not-done-yet.

To me, this post is the equivalent of saying “Hammers suck because I used one once to open a box of glasses and all the glasses broke.”

And to me, this quote is the equivalent of saying “Guns don’t kill people. People with guns kill people.”

In a narrow sense, you are right but the way most people use singletons, isn’t as it’s described in GoF. In this case, it’s a matter of signalling intend. If you implement a class as a singleton, an outside programmer will naturally suspect that it’s used for gaining global access deep from within your program. The uncertainty can be damaging on its own.

Ok, but if we pass around everything in a registry instead, then how can we know what a component does with the passed-around object? I see the same problems as before: The registry grows so big and is used in so many places, that again everything depends from everything.

That is true. There are two things that makes the registry an improvement over a singleton. The first is that it offers a flex-point; This is especially useful in testing, since it allows you to substitute a single component with a mock. The other benefit is that a single monolithic registry is the first step towards a finer grained collection of registries. You can fairly easy refactor towards having a number of registries. Eventually these registries might be possible to turn into actual objects.

But eventually, a registry has one of the same root-problems as singletons; global state. A solution to this could be finer grained registries (As already mentioned) or dependency injection.

The consequence of singletons and static binding is that our code does not work without the global symbol. That’s a constraint, yes, but maybe is it really so much worse than the above constraint? Our component might be so entangled with the entire application, that we don’t even think about reusing it somewhere else.

Put on the extreme end, you are right; What could be said about one static symbol, can be said about every static symbol. There are certainly uses for redefining a seemingly basic operator such as +; Time, money, floating points and other complex types comes to mind. Generally though, I would agree that language features should be kept alone, unless there is some considerable gain to yield from replacing it. However, there is a big difference between not redefining defaults and actively introducing them. What I’m advocating, is that userland code should refrain from introducing new static symbols. I would not suggest to try and “correct” the limitations of the language, using userland workarounds.

Here I imagine some static class methods could be quite useful, to bring some order into the mess. It will still be possible to avoid using the singletons in the OOP application components.

Or not?

I would say that you could equally well write the bootstrapping without singletons, as you can with. They don’t pose much of a problem on this level, mostly because it is already “spoiled”. Eg. you can’t unit-test it anyway, because of all the side-effects, so adding a singleton kind of drowns in the noise.