My main singleton class holds multiple instances of the PDO object (for multiple databases) – the idea being that I have just one instance of each connection class.

When wring my data management objects, these objects require one or more of the db connections. Passing these connections in the cobstructor would require the object invoking the data management object to have an instance of the connection ready – so where would that instance come from?

As for static methods I jsut use this so non-object fucntions can be called using the __autoload() function – maybe this is wrong too, but it suits me very well ;)

@Matt Butcher (on a logger)
Definitely a valid point, and a difficult one to solve. Certainly you don’t want to pass a dependency like a logger to everything in your application. That being said, you’ll also want to avoid hardcoding your logger while not overly-depending on the global state (because I like being able to use my classes independent of everything else). Most any solution here requires some sort of globally-available context.

@cease (on checking on DI in the spring framework)
I agree that singletons will still exist and should in some cases. After all, we ARE responding to one request: there’s something inherently “single” about that. In symfony 2, the service container, while not technically a singleton, is constructed just once and then is available where needed. The spring framework is precisely the model that most new php paradigms are following. In other words, my implementation probably wouldn’t be any different – spring is the model case. There’s some conversation about this very topic (specifically in the comments) here: http://fabien.potencier.org/article/14/symfony-service-container-using-a-builder-to-create-services

@Nate Abele (on nothing inherently bad with static methods, singletons, mutable global states, and referential transparency)
No, there’s nothing inherently wrong with them – you just have to realize what you aim to lose by using them. Namely, your class will have some sort of hardcoded dependency and may be difficult to use in isolation (e.g. testing) because the class looks for some global condition that may not be available. If you’re cool with that (and in a lot of cases you may be) then they’re fine.

Regarding the true problem being with mutable global states, that certainly makes sense. Since immutable globals are essentially constants, if a global constant is really what you’re after, then that’s fine. As an extreme, I certainly won’t stop using real constants (myClass::SOME_VALUE) any time soon.

On the referential transparency front – you’re right again. Hopefully with DI, at the very least, you’ll be less surprised when something proves opaque since scope is clearer. That being said, if your nesting level is deep (the objects in your scope have many objects in their scope), then you may still lose sight of the full “scope” of your actions.

Thanks for the comments!

While both singletons and static method calls are best avoided (generally speaking) I dislike static calls much more than singletons: A singleton has a getInstance() method of which a setInstance() counterpart can exist. Thereby it is possible to alter the getInstance behaviour to return an object of a different type (Ok, so it’s not a singleton anymore but then again, it shouldn’t have been in the first place). And if the application code doesn’t only accept instances of the singleton class but accepts an interface one doesn’t neccessarily have to resort to subclasses of the singleton class for the returned object…

First, let’s be perfectly clear: there is nothing inherently wrong with static methods. Nor, in fact, is there anything inherently wrong with singletons.

The real problems are (mutable) global state and referential transparency. Things that rely on global state are mainly only problematic when that state is mutable. And DI doesn’t solve the problem of referential transparency at all, it just treats the symptoms, making it easier to live with.

Instead of spouting off about high-level design patterns, it’s better to learn about the underlying programming concepts that those patterns try to implement or solve. Then you can actually have a productive discussion.

@author I suggest you still look at the spring implementation of DI. The use of singletons are used within their implementation although it is hidden from end users. The applicationContext initializes beans as singletons that are injected. Would like to hear how you’re implementation will be different.