Court Ewing has written up a post looking at an alternative to a commonly used bad design pattern - the global registry dependency - a method that uses a singleton to control access to a class-wide instance of an object.

This gives you flexibility when configuring and setting your adapter, and it allows you to instantiate a new service without having to explicitly set commonly used dependencies, but you are ultimately just replacing one hardcoded object call with another. This means you are still limited in your ability to unit test the class properly, and you will have a difficult time debugging if you ever need to find out exactly when and where your database adapter was configured.

In his simple solution uses static methods to assign the database adapter when the bootstrap process is started instead of when the object is created. This adapter is assigned to an abstract class, so it's created even outside the class instantiations. There's one caveat to doing things this way, though - depending on the needs, you might have to have more than one abstract class and things could get tricky.

Brandon Savage takes another look at a popular design pattern - the registry pattern - and how he's changed his thinking on its use a bit on how (or if) it should be used in your applications.

Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval. [...] For me, over the last few months, I've discovered two reasons why I advise against the Registry Pattern: first and foremost, it discourages unit testing, and secondly, it discourages good design.

He goes on to elaborate on why these to things could be so detrimental to your code including the problems it can cause in tests being a point of failure and that it can make you application sloppy by giving you an unpoliced "bucket" to drop things in without any context to where they fit in the site.

So what's his suggestion to replace this bit of functionality and make things both easy to test and simpler to keep structured? Dependency injection.

Continuing on from the first part of the series, Marc Plotz forges ahead in his development of a PHP MVC (Model/View/Controller) framework. This new article gives a more complete overview of how the entire framework is structured.

Unlike the previous part, I am not simply giving you the part of the framework that we discuss, but a much more complete version. You will need a MySQL database to run it on, and you will have to setup the connection in application/db.ini.php. My example should guide you. You should not have to do much else than create the database and connect to it.

You can grab the source here and follow along with the tutorial as it steps through bootstrapping and a registry that replaces a "super global" handling method that could cause trouble.

Brandon Savage has posted a quick look at using one of the more popular design patterns - Registry - to handle object storage and retrieval.

One of the biggest challenges in OOP programming with PHP is the ability to pass around objects and let other objects use them. This challenge can be solved with careful design, however. Here we will discuss the registry pattern, not a member of the GoF's original patterns but still an important pattern nonetheless.

He looks at a few different ways to solve a few different problems - first, sharing a database resource between multiple objects, then making sure that you have a connection no matter where its called from and finally - what the registry is used for - sharing multiple database connections between multiple objects. He uses static methods in an abstract class to handle the set/get of the correct object.

There's also a bit of discussion about the registry pattern versus dependency injection and which is better for most instances.

Justin has posted a few cool things that you can do by combining PHP with someof the Windows functionality PHP has access to (either via direct function calls or through the COM object).

Many PHP examples out there are designed for a linux/unix operating system. I am going to give some examples of some interesting functionality that only works with php running in a windows environment (IIS or apache).

Hist list includes little things like ejecting the CD-ROM and sending things to the printer out to working with the registry and listing the current system processes.

Following up on their introduction to design patterns, the PHP Freaks have posted tutorials covering three of the more popular patterns - strategy/bridge, value object and singleton.

• Strategy and Bridge - The Strategy and Bridge patterns provide solutions to apply polymorphism in more flexible way than you can accomplish with only inheritance.
• Value Object - The Value Object pattern has, just like the Singleton, to do with referencing and instances. In a way, the Value Object is the opposite of the Singleton: it's goal is to ensure NOT to use the same instance, under certain conditions.
• Singleton and Singleton Registry - The Singleton pattern ensures that you are always dealing with the same, single instance, wherever in your application. The Registry pattern usually utilizes the Singleton pattern (hence "Singleton Registry") to make the same 'globalness' apply to objects who's classes weren't necessarily designed to

Keep checking back to their tutorials section for more design pattern tutorials.

In this recent post from the Solar blog, anttih shows how to use the Solar registry to automatically load and register objects when it starts up.

Solar_Registry is a class for storing singleton objects which are used usually for things like SQL objects and the response and request objects. Now what's interesting, is that in the new version of Solar a new configuration key registry_set was added for the Solar arch-class. You can use it to tell Solar to automatically add objects to the registry when it starts up.

He compares the two methods - manual loading and the automatic version and includes a "real world" example of loading up an SMTP object.

On the Debuggable blog today Tim Koschutzki looks at another testing topics for the CakePHP framework - a cleaner way for testing models.

Up until now there was always a need to create a so-called test model that extends your model-under-test in order to overwrite its $useDbConfig setting to be 'test_suite'. By that you ensured that your models run with the test_suite datasource when the tests are run. [...] Nate proposed ClassRegistry::config(), which allows you to tell the ClassRegistry class which datasource it shall use when ClassRegistry::init() is used the next time (and thereby a model is instantiated).

He includes an example of the new functionality - a test case ensuring that three articles are there and are marked as published. The registry makes it easier to automatically create the ArticleTest instance inside the test case rather than having to manually declare and define it.

Larry Garfield talks about a new feature of Drupal 7 in a new post to his blog - the new introspective code registry that's been introduced in this latest version.

As a GHOP Task , Cornil did a performance analysis of Drupal and found its two largest performance drains were the bootstrap process and the theming layer. Quite simply, Drupal spends too much time including code. [...] Fortunately, Drupal 7's self-learning code registry system has just landed, which should obliterate most of the wasted bootstrap cost.

Larry describes the "heart of it all", the token_get_all call, that parses through an entire PHP file, splitting out things like classes included and functions called. This is passed through a function_exists call to the current script and, if it's already there, the file isn't included repetitively.

Adam Harvey has a (very) quick post with a hint for PEAR users out there - how to get a list of installaed packages on the system you're using.

I've seen three people ask a variation of how can I get a list of installed PEAR packages from within my PHP script in the last few weeks on IRC, and two just in the last day. Because I'm a helpful sort, here's a little morsel of code that will do just that.

The code loads the PEAR Registry package and loops, via a foreach, through the results from a listPackages() call. It should work with just about any PEAR version.