Registry vs Singletons... I'm surely missing something here.

[Aeglos]

I had written a huge post about this but discarded it. Better get straight to the point.

 

I'm working on a personal MVC framework, using the a singleton registry to pass objects around (database and templates to my controllers for example). But i'm finding that every single object I load to the registry could, instead, be a separate singleton and be called on demand, thus eliminating the need for a registry entirely.

 

So far I could part with the registry and make a singleton for the template, database, validator, log, etc classes, and moving the URI router to front controller, with the same effect.

Is there something wrong with this approach? They all need just one instance to work, no need for multiple validator objects, or multiple database objects, and they all are often called multiple times through the controllers, making it seems that Foo::bar() is far more eficient for coding and readability than instatiating the registry, loading the object in it, instatiating the registry elsewhere when needed, calling the registered object, and the calling the desired method.

 

Perhaps I'm not using the registry at it's fullest?... Using only singletons may also lead to tight coupling issues I think, and seems like a dirty replacement for the global namespace. Is there any advice on this? Or some reading/articles out there that tackle this?

 

Thanks in advance, cheers.

[Jenk]

Singletons are globals. Globals are bad.

 

In my opinion, there isn't a single situation within PHP where a singleton is worthy.

[448191]

Let me try to provide a little nuance to that. 

 

Having statefull objects in the global space can be risky. For starters, dependencies are less transparent. And believe me, that alone is more than reason enough not to use globals, especially when working in a team. Try downloading MediaWiki and see what I mean.

 

There is also the performance issue. Anything static wont be removed from memory during execution. That includes $GLOBALS and static class members like Singleton uses. Reinitializing/constructing is even more expensive, so a Singleton or global Registry is safe enough performance wise if the object is very commonly used.

 

On a sidenote, if you don't make a Registry a Singleton (i.e. a global Registry), IMO you're kinda defeating the purpose of a Registry, which is to provide a well-known and easily accessable object for an entire application. If you can avoid putting an object in the Registry, good money on that being the better choice in the end.

 

A global Registry can be convenient though, and as long you properly document dependencies and don't overuse it (think long and hard about what you put in there), you should be fine. The big bad global wolf wont eat you.

 

I do NOT think it is wise to build a flock of Singletons. If you want to ensure an object is only instantiated once, you can also simply use a static flag and refuse second instantiations.

[Jenk]

On a sidenote, if you don't make a Registry a Singleton (i.e. a global Registry), IMO you're kinda defeating the purpose of a Registry, which is to provide a well-known and easily accessable object for an entire application. If you can avoid putting an object in the Registry, good money on that being the better choice in the end.

Depends - if you have an accessor of $this->registry()/$this->registry in your model, it's better than Registry::instance();.

 

Often this is not the case in PHP as objects which are multi-level extensions are slow, but it other languages this is a much better scenario to achieve.