views:

96

answers:

2

I have a class that I am using all over the place in my code. It contains settings and other core functionality. Here's what I'm doing right now to use the class.

$settings = new Settings();
$settings->loadSettings();

Then, when I need to the code in some random function in another class, I do something like this:

function abc() {
    global $settings;
    $variable = $settings->a;
}

I'm sick and tired of randomly calling global $settings all over the place to pull in that settings object. I don't want to use the $_GLOBALS array (I don't know why, I just don't want to).

I'm thinking I want to switch to have a static class variable called $settings inside of settings. The code would look like this:

Settings::$settings = new Settings();
Settings::$settings->loadSettings();

Then, whenever I want to use it, I never have to worry about sucking it in via the global operator:

function abc() {
    $variable = Settings::$settings->a;
}

Good idea or bad idea?

+6  A: 

Well it's probably an improvement on globals, because it solves all the ugly scoping issues that globals cause. Getting rid of the global operator is generally a good thing! What you are doing is not dissimilar to the singleton pattern, though it's considerably simpler. (See the "Singleton" section at http://php.net/manual/en/language.oop5.patterns.php for more information on the pattern.) Your solution is almost certainly fine for your purposes.

On the other hand, there may be better ways of achieving the same thing that decouple your code more. That is to say, each class becomes more capable of being used in another project without significant recoding. One way to do this would be to "inject" the settings object into each class:

class ABC {
    private $settings;

    public function __construct($settings) {
        $this->settings = $settings;
    }

    public function someMethod() {
        $variable = $this->settings->a;
    }
}

This would be more work, but may improve the re-usability of your code. You could then, for example, write a different settings class for every project but use the same ABC class.

This process, where you "inject" an object into another object that depends on it, is called dependency injection. There are other, more complex ways of doing this, including complex containers. See http://fabien.potencier.org/article/11/what-is-dependency-injection for an interesting set of tutorials on the subject. They're probably incidental to your current needs, but may help either now or in the future.

lonesomeday
Thanks for the awesome answer.
Kirk
+1  A: 

It seems you are looking for a Singleton. Basically the idea is to have a class which has a public static method getInstance() which returns an instance of the class itself. The first time you call the method, it stores the instance in a private property, and all later time it returns the stored instance. In this way, whenever you call Settings::getInstance(), you are guaranteed to have a copy of the same object. Then you can store settings in this object.

Andrea