Does a monolithic "main" class make sense?

Question

I'm working on an application that contains a central class, called Engine, made of different sub-modules (classes), where each module is responsible for a specific functionality. Those modules are private in the engine class, and the engine class itself exposes their work through some public methods. For example:

class Engine:
  public:
    doSomethingFromModuleA() { moduleA.doSomething() }
    doSomethingFromModuleB() { moduleB.doSomething() }
    ...
     
  private:
    moduleA
    moduleB
    ...

The GUI then interacts with those methods via some free functions (think of it as a very lightweight MVC pattern).

In other words, the engine class contains the whole API of the application. Everything the app can do is available on that engine class as a public method.

Now, as I add more features to the app, the engine class grows bigger and bigger. The sub-modules help in maintaining a certain order, however some glue code is still needed in the engine class to make those sub-module talk to each other (e.g. moduleB wants some data computed by moduleA in order to do this and that).

Is having a monolith "main" class a common pattern in large applications?

Answer 1

No it is not common nor practical. Aggregating every feature of every submodule through the Engine interface is not helpful. You should expose the submodules (or interfaces to them) instead. This makes it easier to find features (there's a functional hierarchy) and changing any of the submodules would not have an impact on the Engine class (that is, it would not require you to modify this as well).

Depending on your application it may be beneficial to create your submodules in a lazy manner, only creating hem the first time they are accessed. This could make the startup quicker. You would wrap the interfaces in properties or Get...() methods.