In a PHP project, what patterns exist to store, access and organize helper objects?

user_187606 0
Viewed 13047

How do you organize and manage your helper objects like the database engine, user notification, error handling and so on in a PHP based, object oriented project?

Say I have a large PHP CMS. The CMS is organized in various classes. A few examples:

  • the database object
  • user management
  • an API to create/modify/delete items
  • a messaging object to display messages to the end user
  • a context handler that takes you to the right page
  • a navigation bar class that shows buttons
  • a logging object
  • possibly, custom error handling

etc.

I am dealing with the eternal question, how to best make these objects accessible to each part of the system that needs it.

my first apporach, many years ago was to have a $application global that contained initialized instances of these classes.

global $application;
$application->messageHandler->addMessage("Item successfully inserted");

I then changed over to the Singleton pattern and a factory function:

$mh =&factory("messageHandler");
$mh->addMessage("Item successfully inserted");

but I'm not happy with that either. Unit tests and encapsulation become more and more important to me, and in my understanding the logic behind globals/singletons destroys the basic idea of OOP.

Then there is of course the possibility of giving each object a number of pointers to the helper objects it needs, probably the very cleanest, resource-saving and testing-friendly way but I have doubts about the maintainability of this in the long run.

Most PHP frameworks I have looked into use either the singleton pattern, or functions that access the initialized objects. Both fine approaches, but as I said I'm happy with neither.

I would like to broaden my horizon on what common patterns exist here. I am looking for examples, additional ideas and pointers towards resources that discuss this from a long-term, real-world perspective.

Also, I'm interested to hear about specialized, niche or plain weird approaches to the issue.

oop design-patterns php
8 Answers

I like the concept of Dependency Injection:

"Dependency Injection is where components are given their dependencies through their constructors, methods, or directly into fields. (From Pico Container Website)"

Fabien Potencier wrote a really nice series of articles about Dependency Injection and the need to use them. He also offers a nice and small Dependency Injection Container named Pimple which I really much like to use (more info on github).

As stated above, I don't like the use of Singletons. A good summary on why Singletons aren't good design can be found here in Steve Yegge's blog.

user_2431810
user_2181960

Objects in PHP take up a good amount of memory, as you have probably seen from your unit tests. Therefore it is ideal to destroy un-needed objects as soon as possible to save memory for other processes. With that in mind I find that every object fits one of two molds.

1) The object might has many useful methods or needs to be called more than once in which case I implement a singleton/registry:

$object = load::singleton('classname');
//or
$object = classname::instance(); // which sets self::$instance = $this

2) The object only exists for the life of the method/function calling it in which case a simple creation is beneficial to prevent lingering object references from keeping objects alive too long.

$object = new Class();

Storing temporary objects ANYWHERE might lead to memory leaks because references to them might be forgotten about keeping the object in memory for the rest of the script.

user_999230

I'd go for function returning initialized objects:

A('Users')->getCurrentUser();

In testing environment you can define it to return mock-ups. You can even detect inside who calls the function using debug_backtrace() and return different objects. You can register inside it who wants to get what objects to get some insights what's actually going on inside your program.

user_1669210
user_1831320
Related