Registry design pattern…good or bad?

The article claims it is using the “registry design pattern”; is that the universal name for this design in the industry?

Yes, but the implementation could obviously differ. Basically, a registry is a container for shared objects. In the really basic version, you could use an array. As such, the variable $GLOBALS could be called a registry.

Is there another similar patter out there that would be a better option?

There are two variations of a registry. There is the global registry (Which is far the most common, and which this is an example of). And there is a local registry. A local registry is passed to objects that need it, rather than obtained through a global symbol (static class, singleton etc.). A local registry has a lower degree of coupling, but is also slightly more abstract, so there is a tradeoff there.

You can also go even further and use full dependency injection, where you explicitly pass all the dependencies to the objects that need them. This can be a bit tedious in larger applications. You can couple this with a dependency injection container, which is a piece of code that “knows” which dependencies which classes have. This is even more complex than a local registry, but has a very low degree of coupling.

Is this pattern considered to be good practice to implement in the context of an MVC framework?

It’s common practise. If it’s good or bad is a judgement call. Personally I’m willing to accept some complexity in return of decoupling, but ymmv.

Leave a Comment