Are PHP global constants a good modern development practice?

Question

I'm working on a new project with a sizeable PHP codebase. The application uses quite a few PHP constants ( define('FOO', 'bar') ), particularly for things like database connection parameters. These constants are all defined in a single configuration file that is require_once()'d directly by basically every class in the application.

A few years ago this would have made perfect sense, but since then I've gotten the Unit Testing bug and this tight coupling between classes is really bothering me. These constants smell like global variables, and they're referenced directly throughout the application code.

Is this still a good idea? Would it be reasonable to copy these values into an object and use this object (i.e. a Bean - there, I said it) to convey them via dependency injection to the the classes that interact with the database? Am I defeating any of the benefits of PHP constants (say speed or something) by doing this?

Another approach I'm considering would be be to create a separate configuration PHP script for testing. I'll still need to figure a way to get the classes under test to use the sandbox configuration script instead of the global configuration script. This still feels brittle, but it might require less outright modification to the entire application.

Answer 1

In my opinion, constants should be used only in two circumstances:

• Actual constant values (i.e. things that will never change, SECONDS_PER_HOUR).
• OS-dependent values, as long as the constant can be used transparently by the application, in every situation possible.

Even then, I'd reconsider whether class constants would be more appropriate so as not to pollute the constants space.

In your situation, I'd say constants are not a good solution because you will want to provide alternative values depending on where they're used.

Answer 2

These constants smell like global variables, and they're referenced directly […]. Would it be reasonable to copy these values into an object and […] convey them via dependency injection?

Absolutely! I would go even further and say even class constants should be avoided. Because they are public, they expose internals and they are API, so you cannot change them easily without risking breaking existing applications due to the tight coupling. A configuration object makes much more sense (just dont make it a Singleton).

Also see:

• Brittle Global State & Singletons from
• http://misko.hevery.com/code-reviewers-guide/