Skip to main content
Software Engineering

Return to Answer

Added dependency injection link
Source Link
Joris Timmermans
Joris Timmermans
  • 9.3k
  • 2
  • 39
  • 61

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.

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.

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.

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.

changed a "the" to "an", because the text might have suggested that there's still only a single instance possible, which is not the case.
Source Link
Joris Timmermans
Joris Timmermans
  • 9.3k
  • 2
  • 39
  • 61

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.

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 thean instance of your configuration class any way you like, with any data, for testing.

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.

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 the instance of your configuration class any way you like, with any data, for testing.

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.

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.

Source Link
Joris Timmermans
Joris Timmermans
  • 9.3k
  • 2
  • 39
  • 61

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.

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 the instance of your configuration class any way you like, with any data, for testing.