public function setDb($obj=null) {
if ( $obj !== null ) {
return $this->_db = $obj;
}

return $this->_db = Registry::get(‘db’);
}

you can write unit tests for this class simply this way and you are still using Registry.

When you use a registry as a ‘convenient tool’ to transport objects (holding data that might change throughout code execution) from A to B, alarm bells should start to ring…

That is very true; the Registry should only be used in application code.

I made provision for passing objects along the layers in my own framework so I can easily begin a new application without useing Registry at all.

@Leonard

Very true and that is being openly abusive of the Registry design, developers with little or no understand should just step aside IMHO.

The Registry however should not run the core/framework of your App, it should simply be a convenience.

First, in PHP, there is nothing protecting globals from being changed. Some well meaning, but unknowing, developer might not realize that the “cache” global is already being used. They assign a different value to the variable and are happily on their way. Now you have a bug that is caused because of their code, but manifests itself in yours. These can be brutal.

Second, global state hides dependencies. I usually compare it to “f(X) = Y”. When you plug in X, you should always get Y as the return value. If changing a global affects the result of a function, then it is really a hidden argument. Suddenly, you have to know about the inner workings of the method to understand why f(X) now returns Z. Really, your method is f(X, GLOBAL) = Y. This can be really become a problem when trying to do Test Driven Development. Globals make writing tests a pain in the arse.

Anyway, I recommend taking a look at Misko Hevery’s blog (http://misko.hevery.com/). He has written quite a bit about testability and dependency injection. Suffice to say, he is an avid opponent of Globals (and Singletons).

2) If not using a DI framework, but a ServiceLocator instead, the Registry is a proper fit for all of the configuration-wide objects (database connection, logger, configuration parameters etc.)

That said, it can come in handy… just a matter of proper usage.

…
public function getConnection() {
if( is_null( $this -> db ) ) {
$this -> db = Registry::get( ‘db’ );
}
return $this -> db;
}
…

You now have a default connection or use a setter to set a different one. Too many applications use DI when that is over the top IMHO; do remember the wrong tool can do just as much damage.

1) you don’t know what is using items pulled from the registry, so you don’t know where modifications to those might be being made. It’s a whole new level of spaghetti that makes debugging hell.

2) using keys to reference items in the registry becomes problematic because they are easier to add then they are to document. (For a similar reason, I prefer explicit setters to option arrays, which is another religious debate.)

Registry is seductive because it’s easy right now, while you’re in the code, but it’s a short term payoff.

Great post on why you shouldn’t “overuse” Registry and with alternative solutions.

You can also have a Registry that is neither global nor static, and which is passed around between objects or which acts as an internal registry for an object with many collaborators. We use the pattern in Zend Framework on Zend_Application_Bootstrap, which uses a Registry internally to keep track of bootstrapped resources for later use.

$GLOBALS['cache']->set($key, $value);

I use similar commands for DB access, sending debug info to Firebug, current user data (language, locale, timezone, location, …) and similar. Basically, stuff I need easily accessible from everywhere.

It’s good for me and has never caused me any problems. It’s part of the framework I’ve created. It’s what frameworks are for.

I don’t understand your POV.