Is it bad design to have a class represent your entire program?

Question

Instead of using singletons, I made one class to hold an instance for every component. Let's call it MainApp. MainApp is initialized in the entry point of the program and determines the lifetime of all components and resources. It has a single responsibility and that is being a collection of components. That's why it didn't feel like a bad idea first. However, some components need access to other components, there is one component that is needed for almost all other components. To solve this I used dependency injection, but this makes these components dependent on MainApp. It feels like MainApp just became a big mediator class for all components.

Back to my question: Is this kind of class bad design? What would be better alternatives? Or isn't this class necessarily bad design, is the problem more related to the fact that a lot depends on it?

Answer 1

This MainApp class is not per se a bad idea, but probably reinventing the wheel.

Generally, you need one "central" component to orchestrate the whole idea of dependency injection. Also, you probably are better off with using a readymade solution (e.g. in Java a Weld container.)

However, the services should not depend on MainApp, but on the other services they need. Let's say, you have a User service which needs a Repository service. Your question sounds like you do this right now:

// BAD
class UserService {
    private MainApp mainApp;

    UserService(MainApp mainApp) {
        this.mainApp = mainApp;
    }

    void doSomethingThatNeedsARepository() {
        this.mainApp.getRepositoryService().doStuff();
    }
}

// in MainApp
UserService userService = new UserService(this);

If you do this, you lose control over which service needs which other service, resulting in a big mess.

Only inject what you actually need:

// Better
class UserService {
    private RepositoryService repository;

    UserService(RepositoryService repository) {
        this.repository = repository;
    }

    void doSomethingThatNeedsARepository() {
        this.repository.doStuff();
    }
}

// in MainApp
RepositoryService repository = new RepositoryService(...);
UserService userService = new UserService(repository);

(We might go on discussing the merits of using an interface instead of a concrete service, but somebody else will probably do this ;-))

Answer 2

However, some components need access to other components, there is one component that is needed for almost all other components. To solve this I used dependency injection, but this makes these components dependent on MainApp. It feels like MainApp just became a big mediator class for all components.

Using MainApp as the Composition Root for Dependency Injection does not make anything else dependant on it unless you're doing something silly like letting the other components know that MainApp exists.

MainApp's job is to construct and inject components. It is not something that components should talk to or ask questions of. Stick to that and your design is fine.

Doing this doesn't make MainApp "represent" your entire program. It's simply how you build its persistent object graph. Once that's done MainApp can call start() on some component and step aside, never to be heard from again.

Answer 3

MainApp is fine. It is a composition root. It should act as glue, injecting dependencies, linking producers and listeners, that kind of stuff.

About the dependency injection, avoid injecting MainApp itself (unless some limitation of the platform forces you). Instead, you can have MainApp inject other things, including factories. If you need to create new types just to inject them, great, do that.

Nothing else should have knowledge of MainApp. A change in MainApp should not imply a change of the components.

Answer 4

TL;DR; Injecting your MainApp class loosly couples it to everything it's injected into. Your MainApp class will become the place to solve all sorts of problems because, as you say yourself, it is now a mediator for everything it's injected into. Just inject what is needed for each class, nothing more.

Longer explanation:

It looks to me that you've created an Inversion of Control container or IoC for short. This actually underpins the dependency inversion principle as determined by SOLID architecture. The idea is that a central repository understands how various parts of an application can be constructed and will either hold a reference to an instantiated instance or at least have the ability to construct a new instance with minimal configuration.

Many languages that make use of reflection can actually take this a step further by statically analysing the various dependencies a class needs and then recursively constructing those dependencies based on its knowledge of how they are also constructed. This can be incredibly powerful when building an application as all you need to do is register a class with the IoC and instantly allow the automatic construction of some quite complex dependency trees.

You don't appear to be to far away from this kind of design right now, but you mustn't inject your MainApp class into other classes. This does create dependencies on your registry when you really want to ensure it remains decoupled. Instead you should be looking to construct your classes using the instances of classes it actually needs, not by passing in the registry and letting your classes pull out what they want.

Depending on the language, there are already some excellent IoC implentations available for you to draw inspiration from:

• PHP - PHP DI
• C# - Scott Hanselmans has a list of many IoC implementations
• Java - The spring framework has a pretty robust IoC implementation

And so on.