Is there ANYTHING bad about the Registry design pattern?

Question

Is the Registry design pattern a good solution for this in PHP?

For a social network site (facebook, myspace).

let's say I have a Database class which creates a single DB connection and lets me do DB stuff and a Sessions class which lets me handle sessions as well as a Cache class which lets me cache items and retrieve them. SO that is 3 main classes that I will need to be able to access on every page of my site. After reviewing the Registry Pattern for the past hour, I am thinking that it is the perfect solution maybe. I can store my Database, Session, and Cache objects into a registry Object and then Inject the Registry object into every page or every other class and have access to my database, sessions, and cache.

Before this I was using a singleton pattern so I would have to call my singleton method for all 3 of my MAIN classes inside of every page or other class.

So I am just wondering is there any downfalls of using the Registry class? 1 that I can see is it seems it may be harder to see what classes depend on which other classes and such. Other then that it seems like a great solution for this, also I saw another post on here of a user's registry class where they were storing setting in the registry an having access to them in all the other classes that the registry Object is passed into, I am sure I will find a good use for that feature as well.

So the only question here is am I missing something or did I just hot the lotto?

---

UPDATE

Also if using a registry to store objects in, should I do something like this...

$this->session = $registry->getObject('session');

or this instead

$this->registry->session = $registry->getObject('session');

The second method seems like it would maybe be easiar to understand where the object came from?

Answer 1

You mean a registry of Singletons, right? If so, it sounds like all you really want is access to three global objects everywhere, but contained inside another object.

So if you wrote cache.php, sessions.php, and database.php, which define the classes Cache, Sessions, and Database, you want to contain them all inside a Registry object defined in registry.php.

First of all, it's great to control the ORDER of instantiation this way. It's better than simply doing a require_once of cache.php, sessions.php, and database.php, and inside of them you define not only the class but the single global instance of it. That controls the ORDER of instantiation by how you include/require it. Kind of sleazy. Better to have your Registry object, that when it gets created and becomes a $registry global, first thing is does is control the creation of your globals in the order and how you want.

Second of all, it's great to have a single Registry.php that has a single $registry global. Defining globals here and there over various files gets hard to manage.

Now that I've agreed with you, I pose an important question to you. How do you see these being different:

$registry->getObject('session'); $registry->getObject('database'); $registry->getObject('cache');

versus:

$registry->getSession (); $registry->getDatabase (); $registry->getCache ();

Personally, I like the latter. You aren't using a string "session" to refer to a Session object, obtained through a super-generic getObject. Instead, you are using getSession() to get a Session. It reads better.

Your registry, after all, knows all about the three globals, it creates them explicitly, so it's already locked into a single purpose. Adding concrete methods also tied to its single purpose isn't "weak" or "bad". Instead, I think it's less code and easier on the eyeballs.