Pattern for objects initialization at startup

Question

I'm building an application and as time goes on, I have more and more objects to initialize at startup. Moveover, some of the newer objects depend on others so I'm getting some kind of spaggetti initialization where objects are created then passed to other constructors. I'm suspecting that I'm getting it wrong.

For example I have a WinForm which accepts a "Controller" class and 2 events. The controller needs to be told about the existence of a DataGridView from the WinForm so it has a method

Controller::SetDataGridReference(DataGridView^ dgv)

Is there a general method of instanciating objects at startup then referencing those objects to each another?

I've been told that putting all the required classes as constructor parameters is a good practice but frankly, I don't see how I can do that here.

I don't really think that the language matters

Answer 1

This looks like a textbook case for using dependency injection (DI). It will certainly help with your spaghetti code and can even assist with unit testing. If you want to make a gradual migration towards DI you might want to consider refactoring the objects with similar relationships and using a few sets of factory classes that can handle all the boilerplate chain intialization as well as centralizing where all that takes place in your code base.

I can recommend Google Guice as a good DI framework for Java. Even if you arent using Java it is a good DI model to compare against other language's DI frameworks

Answer 2

Use the Controller Design Pattern.

That is, create a SINGLE class that will be instanced on program initialization, called Controller. On the constructor of that class, create all other objects. Whatever object that needs any other objects should receive said object as a parameter on its constructor. No one, no absolutely any other object should create anything on their constructor. Pass everything as parameters on their constructors. Also, on the Controller class destructor/dispose call all objects destructor/dispose method in reverse order. This won't reduce your code, but it will make if far better to understand and debug later on.

Answer 3

Dependency Injection should help here: at application boot you can choice to build the complete (or sort of) graph of objects. The entry point of your application will instantiate the DI container of your choice, the you just request the root object.

For example Google Guice comes with a very nice Object grapher.

Answer 4

Two patterns pop into mind as possibly appropriate depending on the specifics of your problem:

1. Abstract Factory Pattern. This can work with or without the Dependency Injection approach suggested by @Scanningcrew.
2. Mediator Pattern. Construct a mediator. Pass the mediator into the constructor of each object. Have each object register with the mediator. Then the objects don't need to know about each other explicitly. This works well when you have a set number of objects interacting with each other.

Answer 5

For the objects interaction, I would go for a Mediator. Check out this definition:

"Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently."

For the instantiation, I would consider the Dependency Injection. Remember that you can freely use and mix design patterns to achieve your goals.