On the php|architect site there's a recent post that splits apart the singletons versus static methods debate that seems to com up every once and a while with a better suggestion - dependency injection.

Much more important than performance is the fact that both static methods and singletons suffer from major drawbacks. When it comes to deciding between the two, you might forgo the benchmark comparison and choose the third-party candidate: dependency injection.

He mentions the "dark side" of both static methods and singletons and how dependency injection can help rid your code of both. Instead of focusing just on the benchmark numbers, DI helps you keep your code more well-structured and "smarter" by scoping things to where they need to be and making them easier to test.

Sebastian Bergmann has a new post to his blog (part of a series on testing techniques for testing that difficult code) about the hard-coded dependencies required by your code and how to stub them for easier testing.

A mock object can be used anywhere in the program where the program expects an object of the mocked class. However, this only works as long as the object can be passed into the context where the original object is used.

Ideally this wouldn't be a problem - handled correctly, dependency injection would make it a non-issue. But, because it has been known to happen, PHPUnit gives you the ability, via the set_new_overload method, to capture that object definition and mock it with a reference to another method in the test class.

Sebastian Bergmann has written up a post for his blog recently that looks at unit testing singletons, something that's been rumored as being some of the hardest to test.

I frequently quote Miško Hevery with "It is hard to test code that uses singletons." And then my audience asks me... Why is it hard to test code that uses singletons? Lets have a look at the default implementation of the Singleton design pattern in PHP.

He defines a singleton first, showing how it's used to create single instances of objects and, because of this, cannot be tested easily because there's no way to know you're getting a clean instance every time. Dependency injection can help with the problem by allowing you to pass in a "mock" instance of the singleton class each time. He also mentions some variations on singletons that could make it easier to test in the future.

In a new post to his blog Giorgio Sironi looks at how using dependency injection in your applications can help keep you from writing the same code over and over:

Is Dependency Injection difficult? Is it hard to do? Certainly it provides value. Particularly in Php, but also in other object-oriented languages, Dependency Injection gives steroids to the process of class reuse, designing components as loosely coupled objects.

He explains a bit of what dependency injection is all about, how it fits in with unit testing applications and a few examples of how it might look in some sample PHP classes. He shows how a bit of refactoring can remove dependence of one class on another and how the factory pattern can be used to correctly create an instance your first class might need.

In this recent post to his blog Benjamin Eberlei talks about the combination of the dependency injection functionality the Symfony framework offers and the Zend_Application component of the Zend Framework and how to make them play well together.

As a follow-up to my recent post on Dependency Injection containers and Zend_Application I was eager to find out if its possible to integrate the new Symfony Dependency Injection Container into the Zend Framework. To my suprise its possible without having to make any changes to one of the two components.

His example use case shows the Zend_Application object being used to add a sfServiceContainer via a setContainer call. There is one strange issue in the integration, though - the Symfony container is case-sensitive for the service names but the Zend Framework makes them all lower-case.

In this new post to his blog today Sam Hennessy continues his "dependency injection manifesto" series and shares why he wants it. The previous parts talked about what DI is and what he wanted from it. This time he talks about why he wants it included.

A DI framework is predominantly interested in the creating and plumbing together of objects. The work of creating and plumbing together objects is mostly very simple, as such do don't need a framework to do any of it. [...] In the end, the reasoning for using a DI framework should be the same reasoning for use of any library or framework.

He breaks it down into a series of reasons why it would be beneficial to the general PHP development community:

• Increased usability
• Easier to maintain
• Makes for simpler unit testing
• Less invasive code
• Removing the need for boilerplate code

There's lots more good stuff in there than this, so be sure to check out the rest of the post for more of his thoughts.

New on his blog today Benjamin Eberlei has posted his own look at dependency injection containers in PHP applications, specifically with the Zend_Application component of the Zend Framework.

Much has been written on Dependency Injection lately [...]. Its an awesome pattern if used on a larger scale and can (re-) wire a complex business application according to a clients needs without having to change much of the domain code. Beginning with version 1.8 Zend Framework is able to integrate any of these DI containers into its Zend_Application component easily.

He gives an example of this integration, adding in the creation of the container as a part of the bootstrap setup (a getContainer call on the front controller object). He also introduces the Yadif DI container (a lightweight container written by Thomas McKelvey) and how to set it up including its own configuration file.

Fabien Potencier has blogged about a tool he's created, a small dependency injection container for PHP 5.3 he mentioned previously - Pimple.

Some people emailed me about a blog post I wrote some time ago about a dependency injection container done in PHP 5.3. I have published on Github the small version of it (Twittee), but not the "working" version.

So, he's updated the Pimple source on Github with the latest and greatest for you to grab and use as you see fit. Remember, it does require PHP 5.3 (currently not released), so you couldn't (shouldn't!) use it in production yet.

Sam Hennessy has continued his series looking at dependency injection in PHP with part one (technically the second part, here's part 0) - what he wants out of a dependency injection framework.

This article is part of a series where I will go into great detail about Dependency Injection (DI) and how it applies to PHP. I will layout exactly how I think DI should be used in PHP with the creation of a new code project as the result.

He has made a list of things that he's want a DI framework to do for him including:

• functionality that helps to keep things manageable
• making it all testable
• make a reduction in the need for "boilerplate code"
• work completely standalone if need be

Sam Hennessy has posted the first part (part 0, actually) of a manifesto he's been working oup about dependency injection in PHP applications.

This article is part of a series where I will go into great detail about Dependency Injection (DI) and how it applies to PHP. I will layout exactly how I think DI should be used in PHP with the creation of a new code project as the result.

The series is his outlet to share some of his thoughts and feelings and some of the experience he's gathered during his time working on a dependency injection framework of his own.

This series I will be putting forward my honest opinion. The thinking will be based around the use of DI in PHP shops with many projects of differing sizes. As such my opinion will not be what everyone needs. This will not be a tutorial but I will provide links so that people new to the concepts can look them up.