php application global settings

I have read almost all question I have found on StackOverflow on this topic, but could not find a straight answer.

Here is my code:

Application class

<?php
    class Application extends Settings {
        public f开发者_StackOverflowunction __construct($env, $cacheDir, $configFile) {
            self::$_env = $env;
            self::$_cacheDir = $cacheDir;
            self::$_config = $this->loadConfig($configFile) // reads configs from xml file into Config object
        }

        // other methods
    }
?>

Settings class:

<?php
class Settings {
    protected static $_env = null;
    protected static $_cacheDir = null;
    protected static $_config = null;

    public static function getEnv() {
        return self::$_env;
    }

    public static function getCacheDir() {
        return self::$_cacheDir;
    }

    public static function getConfig() {
        return self::$_config;
    }
}
?>

I access settings from anywhere in my code like this:

<?php
var_dump(Settings::getEnv());
?>

I want to access Settings form many different places. All values can be set only once and cannot be overwritten (so registry with __set methods do not work, because I can set any value from any place in any stage of application process)

Questions:

Is it good practice to store global settings like this. What downsides of this method? Maybe there's a much better way to do this?

Thank you for your answers

Like Wrikken pointed out in the comment to your question, you are introducing Global State to your application. Quoting Martin Fowler on Global State (PoEAA, pg. 482f):

Remember that any global data is always guilty until proven innocent.

which in a nutshell means: avoid it. I leave it up to you to research on that topic though because it's out of scope for this question to discuss it in detail.

Now, for a better alternative

Let's assume you route all traffic to an index.php. You could then simply bootstrap/build all the components you need to fulfill the request inside that file. For instance, like this:

spl_autoload_register(
    function($className) {
        static $classMap = array(
            'request' => '/path/from/here/to/Request.php',
             … more mapping
        );
        require __DIR__ . $classMap[strtolower($className)];
    }
);

$config  = parse_ini_file(__DIR__ . '/path/from/here/to/config.ini');
foreach($config['env'] as $key => $val) {
    ini_set($key, $val);
}

$router = new Router;
$router->registerActionForRoute(
    '/product/list', 
    function($request, $response) use ($config) {
        return new ProductListAction(
            $request, $response
            new ProductMapper(
                new ProductGateway(
                    new MySqli($config['db']['host'], …),
                    new Cache($config['cache'], …)
                ),
                new ProductBuilder;
            )
        );
    }
);
$router->registerActionForRoute(…);
$router->execute(new Request($_GET, $_POST, $_SERVER), new Response);

Granted, you rather want to include the autoloader from a separate file (because you want to autogenerate it with something like https://github.com/theseer/Autoload). And of course you could replace the closures in the Router with Builder or Factory patterns. I just used the simplest thing possible. It's (hopefully) easier to understand this way. You can check http://silex-project.org/ for a micro-framework using a more sophisticated but similar approach.

The main benefit of this approach is that every component will get what it needs right from the start through Dependecy Injection. This will make it easier to unit-test your code because its so much easier to mock dependencies and achieve test-isolation.

Another benefit is that you keep construction graph and collaborator graph separate, so you dont mix up those responsibility (like you would with a Singleton or otherwise putting a new keyword into classes that are supposed to be Information Experts.

Your Application class should not extend Settings as there is no relationship between the two classes. Instead you should use dependency injection to include the settings into the Application class. There is an example of this below and I recommend reading up on dependency injection.

class Settings {
    // public to simplify example, you can add setters and getters
    public $_env = null;
    public $_cacheDir = null;
    public $_config = null;
}

class Application {
    protected $config;

    public function setConfig($config) {
        $this->config = $config;
    }

}



$app = new Application();

$config = new Settings();

$config->_env = 'dev';
$config->_cacheDir = '/my/dir';
$config->_config = array(/* Config here */);

$app->setConfig($config);

As mentioned by marcelog in another answer you could use a bootstrap class to handle the injection of the config, as well as other objects, into your Application class.

A basic example of a bootstrap class:

class Bootstrap {

    protected $application;

    public function __construct(Application $app) {
        $this->application = $app;
    }

    // connivence method
    public function init() {
        $this->initSettings();
    }

    public function initSettings() {
        $settings = new Settings();
        $settings->_env = 'dev';
        $settings->_cacheDir = '/my/dir';

        $config = array(); // load config from file here
        $settings->_config = config;
        $this->application->setSettings($settings);
    }

    // other init methods
}

$app = new Application();

$bootstrap = new Bootstrap($app);

$bootstrap->init();

These are very basic examples and there is nothing stopping you from writing magic getters and setters, having the bootstrap call any method that begins with init, etc...

Can you post some more code? just to show how are you accessing those settings.

anyway, you could create a Boostrap class. This bootstrap class will do anything necessary to have working environment for your application (thus, moving out the bootstrapping code from the application and settings, to this class).

it can also instantiate a Settings object, which should be a singleton.

in the Settings object, you can use magic methods (__call, __get) to access the different settings, like Settings::getSettings()->getConfigDirectory(). This magic method will strip the "get" word from the call and try to give a resource with the given name (in this case, a setting named "ConfigDirectory").

This is similar to what Zend Framework does in their Zend_Application, Zend_Bootstrap, and Zend_Config classes, you might want to check them out to get some ideas.

as a side note, i don't see (conceptually speaking) why an application should extend settings. An application should have some settings, but that's quite different from extending them.