C++ – Best Practices for Creating a Global Config Class

cstatic-access

I have a large project with a driver part and about 5 libraries doing various associated tasks. Many of the libraries require access to 'global' configuration data which is read from a database at startup by the driver code. By driver I just mean the part which contains the main function.

My idea on how to handle this was to create a config class with a static method to get the config items. Is this the best approach? How else could this be achieved?

eg:

class config {
 public:
   static get_item(key);

 private:
   static values;
};

Is singleton design appropriate here?

Best Answer

The non-singleton way is to create a regular configuration class with regular properties / members, instantiate that object with the correct settings from the database in the driver, and pass the instance to all of the libraries - probably through a std::shared_ptr. This is a common design pattern called Dependency Injection.

That way you avoid all of the potential issues from the singleton design pattern and your code will be more testable as you can instantiate an instance of your configuration class any way you like, with any data, for testing.

Related Solutions

Php – Static is bad, but what about the Factory pattern

Static isn't "bad", it's unmockable. You can still use it where mocking doesn't make sense.
That isn't a Factory pattern, it looks like a Repository pattern, although it may not be. Factory is where you have multiple classes with the same interface / base class and you want to separate out the logic which decides which class to return. Repository gets the data from its repository, abstracting out the implementation of that repository (the Article doesn't need to know if its options are stored in the same DB, another one, an XML file, a CSV file, whatever).
You've ignored the possibility of giving the Article class an ObjectFactory (or Repository, or whatever) object in the constructor on which it can call the buildFromArticle method.

My PHP is rusty, but I think it looks like this:

class Article
{
    private $_option_repository;

    public function __construct($option_repository) {
        $_option_repository = $option_repository;
    }

    //[...]

    public function getArrOption(){
        return $_option_repository->buildFromArticleId($this->getId());
    }
}

I think this fulfils all of your pros above.

C++ – Interfacing application code with unit tests

I think testing public methods are enough most of the time.

If you have a great deal of complexity in your private methods, then consider putting them in another class as public methods and use them as private calls to those methods in your original class. This way you can ensure both methods in your original and utility classes work correctly.

Relying heavily on private methods is something to consider about design desicions.

Best Answer

Related Solutions

Php – Static is bad, but what about the Factory pattern

C++ – Interfacing application code with unit tests

Related Topic