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.
In my opinion, constants should be used only in two circumstances:
SECONDS_PER_HOUR).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.