In response to some of the comments made on his previous post about why you should use dependency injection in your applications, Charles Sprayberry is back with some more concrete examples showing how it all works with some code to back it up.

To help better explain each of the three aspects of DI I discussed in the previous article I'll be going over each more thoroughly and with those code examples requested. I'll be going through each point one at a time as the explanations will likely be of some length compared to the original post.

He starts with the "villain" of the story - the Singleton design pattern, a difficult to test method that lulls you into thinking you're not in the global scope. He talks about the problem of using this approach and how the Factory design pattern can be used to create an alternative. He changes up the example to create a "DbTableFactory" class that can be used to create the objects needed - in this case a "UserTable" object with the connection injected into it at construct time.

Fabien Potencier has posted the ninth part of his "build a framework on Symfony2 components series. In this latest tutorial he takes the simple framework he's already created (complete with some unit tests) and makes it easier to extend.

Our framework is still missing a major characteristic of any good framework: extensibility. Being extensible means that the developer should be able to easily hook into the framework life cycle to modify the way the request is handled.

He chooses the Observer design pattern as a basis for his example, allowing any kind of behavior/actions to be added to the framework's execution. He includes the Symfony2 dispatcher to make this work and includes the code for a "handle" method to fire off events. It executes a "ResponseEvent" every time the framework is executed. An "addListener" method provides the hook to apply a callback to an event - in his case an anonymous function (or closure).

In a response to a recent post on DZone.com about the "Open/Closed Principle" Josh Adell has posted an example of a " flexible and extendable command invocation solution" implementing this SOLID idea.

Let's overcome some of these issues [with only being able to extend the invoker class and that the invoker needs to know how to create commands], and also make the code even more extensible. I'll use a simplified command invoker to demonstrate.

His code is included - the creation of a "Command" interface and two comments that implement it: "HelloCommand" and "PwdCommand", each with "register" and "execute" methods. His "Invoker" class then only needs to be told how to map these commands and the "register" is called as they're needed. You can find the full example code for this invocation example in this gist.

On PHPMaster.com today there's a new article introducing you to the Command design pattern and looking to help you understand its use a bit better.

The majority of [cell phone] users have opted to receive an email, but a significant number are now opting to receive the notifications via SMS. Here's the problem: How do you send a message via two different channels to both groups of users? The logical approach would be to split the users into 2 groups, email recipients and SMS recipients, which would involve running 2 different queries and sending the codeword to each group separately. Using the Command Pattern, which I will introduce you to in this article, you can send the message to both groups of users in a single process.

He uses the message queue he mentioned as an example - showing how you can can queue up different kinds of objects (actions) based on a common interface into the same process. He creates a "DailyAlertEmail" and "DailyAlertSMS" classes, both with a "send" method. The settings for these are then pulled from a database and the "execute" method on the "MessageQueue" class is called to loop through them, calling "send" to do that work.

On PHPMaster.com today there's a new design pattern-focused that introduces you to using the Factory method to create new objects on the fly.

The Factory Method pattern is a design pattern used to define a runtime interface for creating an object. It's called a factory because it creates various types of objects without necessarily knowing what kind of object it creates or how to create it.

Code is included showing how to make creating "Product_*" classes as simple as calling a "build()" method with the type. A slightly more complex situation is also included - building factories inside of factory methods. For more about the Factory design pattern, check out its Wikipedia page (that includes some common uses and some pitfalls to watch out for).

In a recent post to his blog Devis Lucato introduces the "Inversion of Control" design pattern and shares an implementation he's created as an illustration - a Service Locator called Select.

[In a Service Locator] all the dependencies are provided by a builder, which serves as a registry of dependencies and/or service definitions. The service locator knows how to instantiate each dependency. Such service exposes methods like 'getMailer()', 'getLogger()' etc. A service locator centralises the configuration detailing classes and parameters involved on objects instantiations.

He includes some sample code showing the structure of a Select implementation using a "Mailer" identifier and definitions of the classes to load for it. He also includes a bit of documentation of the (simple) API you can use to work with the tool - setting namespaces, replacing class definitions, creating definitions and finding the resource associated with a definition (to name a few).

On DevArticles.com today there's a new tutorial posted talking about one of the more popular design patterns, the Singleton, and how it can be implemented in PHP.

Though in the past they enjoyed both popularity and a certain amount of prestige, without a doubt Singletons have progressively become one of the most evil and despicable villains in object-oriented design. Singletons earned their bad reputation for a reason: bringing them to life requires the programmer to deal at least with a static method. This is simply an elegant masquerade for creating a global access point (which in most cases is mutable as well) throughout an entire application. And we all know that global, mutable access is unquestionably a bad thing that must be avoided at all costs.

In this first part (of two) of the series they introduce the Singleton pattern and show how, via an example of using a database adapter interface to work with a MySQL database, in a tightly coupled example. In the second part of the series, they'll show how to break these apart using dependency injection.

On the Liip blog Bastian Feder has announced the first release of a tool that helps you proxy your objects (overlay them with a layer that exposes properties and methods) following the proxy object design pattern in PHP.

The outcome is this little library making it much easier to generate a proxy of your system under test (SUT). Another thought on this library was, that it should be very easy to use if you know the way to mock classes and methods in PHPUnit. Proxy-object has almost the same API, but does not change the behavior of the proxied class/method. The only purpose is to expose hidden methods and members.

The scripts, found on github, give you a simple way to define a proxy over a given class' functionality and define methods/member variables to be exposed. He includes two code examples, one of each type. There's also an example of making the proxy object without calling the constructor, useful in certain cases when the initialization of the object doesn't need to happen.

You can also find out more about the usage of this tool in this new post to Bastian's blog.

In a new blog post Matthew Weier O'Phinney has taken a look at proxy objects (the Proxy design pattern) and how it differs from some of the other popular patterns.

Of the other patterns mentioned, the one closest to the Proxy is the Decorator. In the case of a Decorator, the focus is on adding functionality to an existing object -- for instance, adding methods, processing input before delegating to the target object, or filtering the return of a method from a target object.

Proxies stand in for objects and have several benefits for your application that may or may not need all of the overhead a full object could cause. Matthew focuses on one benefit in particular - consuming and controlling access to another object. He sets up a problem of wanting to use properties/methods on objects that aren't exposed directly (like a protected method). His solution is a proxy layer class on top of the original object. He includes a few "gotchas" to look out for when using this technique including overwriting all necessary methods and copying over all of the needed properties.

Lukas Smith has a suggestion for developers out there who get the idea to start messing with the order of the parameters of PHP objects/methods - play nice. His example is specifically with Exceptions.

This is just a short follow up to a recent tweet of mine. I have seen this repeatedly happen, even to top notch and usually very careful developers (*). I am not sure why this mistake happens so frequently, but quite often you see code that changes the parameter order for custom Exception constructors. I guess it's mostly because in these cases the developer wants to pass some magic parameters that contain the message (and potentially also the code).

He recommends that, if you really do need to change something like the order of the parameters, use something like a factory to handle the reorganization for you.