So that I don't forget how to do this next time around. Worked for me, your mileage may vary. First step is to get a working install of PHP. [...] At this point, you should be able to open up a Command Prompt, and type 'php -v', and see the response 'PHP v5.4.latest …' appear as expected. Now for PEAR itself.

He gives step-by-step instructions on how to get PEAR up and running - downloading and configuring it with the correct Windows-based paths and using the PEAR_ENV.reg file to update your registry.

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.

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.

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.

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.

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.

• 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.

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.

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.

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.