C++: What is the proper way of organising a programs subsystems?

Question

Imagine you have a large application project, the code is split into a range of subsystems implemented as classes derived from CBaseSubsystem.

Here already comes my first question:

• Is it a good idea to organize subsystems as classes [derived from a base class]?

Then, you have your subsystem classes. Now, you will need create have instances of them somewhere. But where?

• Is it a good idea to have every subsystem instance stored in a global variable, for example:
  extern CEventSystem* g_EventSystem;

• Where should the instances be actually created? All together in a main()-like function?

• Or is it better to avoid global variables entirely and organize the instances in a CSubsystemManager class or the like?

• Would using singleton classes be an appropriate approach?

Answer 1

My solution would create a combo of a singleton Registry, AbstractFactory and Factory.

//in base module

class ISubsystem{} //an interface for a subsystem

//in module code
Registry::instance()->registerFactory("subsystem1",new Subsystem1Factory());

//in user code
IFactory* factory = Registry::instance()->getFactory("subsystem1");
ISubsystem* subsystem = factory->createObject(...); //you can implement whatever policy in factory impl. (like singleton etc.)

Answer 2

If you want to talk theory rather than provide a concrete question then consider designing in terms of a combination of Factory and Singleton with the possibility of Strategy in subsystems which may implement a similar operation for a range of different object types.

The main subsystem Factory is itself a singleton whose purpose is I hope obvious. Use lazy evaluation to allow only required subsystem objects to be loaded as needed. You may want to consider providing each subsystem with a reference counting mechanism which will allow them to be dropped when no longer needed. Some subsystems may themselves be singletons and/or may also implement Strategy pattern to provide a particular service for a range of class types. This service may be for example validation, rendering, serialisation etc.

The value judgement of whether it is a "good idea" to build your application in this way is not for me to say. I would rather let older wisdom speak to that.

Answer 3

Very similar to this. I'd avoid Singleton, because it is absolutely unnecessary here and brings about many other issues.

Create the instances in a main-like routine. If something needs a system, provide access to it through some means, be it a parameter passed directly to that something or a container that provides access to these systems (IE: CSubSystemManager). You likely don't need to go so far as to write CSubSystemManager.

Avoid global state, there's a reason it has a stigma.

Answer 4

If you need a way to access an instance of each subsystem, I would avoid using "extern" and instead go with a singleton that gives you access to an instance of CSubsystemManager. The manager itself can take care of instantiating and managing your subsystem objects.