What is the best way to handle multiple object dependencies in C++?

Answer 1

I would say having factories with static class methods to create objects as needed -- if they don't keep state themselves -- is probably a better solution. If the objects are needed everywhere and need to keep global state, then using the Singleton pattern may be justified. I'd really need to know that the factory methods and recreating the objects as needed wouldn't work before I'd look at Singleon, though. Using Singleton will complicate your testing efforts.

Answer 2

You can make your GlobalState, Log, DAL classes singletons:

class GlobalState {
public:
  static GlobalState& getInstance();
protected:
  GlobalState();
  GlobalState(const GlobalState&);
  GlobalState& operator= (const GlobalState&);
private:
  static GlobalState* p_instance;
};

static GlobalState* GlobalState::p_instance = NULL;

/*static*/
GlobalState& getInstance() {
  // TODO: acquire lock if multi-threaded
  if (!p_instance) {                 // first time?
    p_instance = new GlobalState(); // create sole instance
  }
  // TODO: release lock if multi-threaded
  return *p_instance;               // sole instance
}

Then, inside your various methods,

Honda::MyMethod() {
  ...
  const GlobalState& my_state = GlobalState::getInstance();
  ...
}

You can further simplify your life (and reduce the amount of code duplication) by defining a singleton C++ template, under certain conditions (e.g. all classes' constructors take the same number and types of arguments, etc.)

Answer 3

The nice thing about making state objects into singletons is that you no longer have to pass const references to them into all your constructors anymore.

So, if your, global state were defined as suggested by Vlad R, you could refer to it within the constructors (and elsewhere) using, e.g.:

GlobalState::getInstance()

and therefore remove the constructors' parameters as well as the member variables, making your interfaces cleaner.

Answer 4

I use globally-named instances for most of my global state objects. The pattern is similar to the traditional singleton, except that with the singleton, purists will insist its constructor also be private to prevent independent construction, whereas my pattern allows independent construction as necessary (ie: my singleton template doesn't require the singleton class's constructor be private). Otherwise the pattern is similar to what Vlad wrote out.

One thing to be careful of: if you need to de-allocate your singletons at program exit (for example, you have an imposed requirement that you not leak memory you allocated), handling that can get very messy very fast. Describing all the things I have had to muck with to try to achieve no memory leaks using singletons would take up way to much space, and many of them are not pretty; so if you need cleanup, consider using simple globals instead (as methodologically distasteful as that may be).

Answer 5

You could make use of the Service Locator pattern. This article introduces both dependency injection (which you are currently using) and service locator.

However, consider this: the idea of dependency injection is to have a system where each component has a well-defined responsibility and minimizes knowledge of other components where possible. If the component needs other components to do its job, then these are explicitly passed to it. This makes the component simpler to understand, more likely to be correct, and easier to maintain.

If you regularly need to add components which need to be known throughout the system, then there may be something wrong with the design of the system (or the way new features are being added to it). The dependency injection pattern just results in this problem being explicitly visible.

Answer 6

use a singleton and don't forget about: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12

Answer 7

To answer your question, Michael, there are effectively four different things that you can do in this situation:

1. Make all your utility objects into globals.
2. Change all your utility classes into Singletons.
3. Use a Service Locator.
4. Use Dependency Injection (which you are already doing)

Let's address the first three options:

1. Using globals might be convienent, but it hides the object dependency and makes testing in isolation more difficult.
2. It's not a good idea to use Singletons.
3. It's not a good idea to use a Service Locator.

Therefore, keep using Dependency Injection.