iOS VIPER architecture, who has to instantiate a whole module?

Question

Taking into account the VIPER structure

I have two modules, A and B. The first module A, via presenter, wants to perform an action that has to be done in the module B, so tells its wireframe to do it. The question is, who is responsible of instantiate the whole module (view, interactor, presenter...). I saw some examples with different approaches:

• Create all the modules in the beginning of the app.
• Create the whole module in the wireframe of the module, so in this case a class method of BWireframe instantites all the B module.

Taking into account that the wireframe is responsible for routing, is it also responsible of creating its module?

Answer 1

TL;DR: I would recommend you should use a DI framework like Typhoon and let that handle instantiation.

The reason you probably won't want your wireframes instantiating everything in a VIPER modules (View, Presenter, Interactor, DataManager) is that you'll be creating dependencies directly to each of those components.

Dependencies make software resistant to change: if we think of it with our onion architecture / hexagonal architecture hats on, the wireframe would cross the boundaries of at least two separate layers of your onion by knowing about not only the view, but the data manager.

This forces us to treat wireframes as a generic infrastructure class: i.e., something on the outer-most layer of your application.

However, this contradicts with the wireframe's other (and the more real) responsibility: doing navigation. While this is still the infrastructure layer, it belongs firmly and specifically in UIKit (-presentViewController: etc.).

So IMHO, VIPER's wireframe is doing too much.

The only sensible thing is to split the two responsibilities:

1. initialization of VIPER classes: you can introduce a factory, or use DI tools which are designed to solve this problem
2. doing navigation: this stays within the remit of a Wireframe.

Additional notes

If you're wondering "who instantiates the next module?", then again, IMHO, I think it's not right that some Module A's wireframe talks to Module B's wireframe despite what the VIPER post says.

The reason is that Module A would now be made to depend on Module B, causing a tight coupling: this defeats the purpose of modules. Much more discussion about this topic over at VIPER-TODO project at GitHub =]

Hope this helps.

Answer 2

I think that the entering gate to a module is the wireframe so I agree with your second approach.

Creating a module includes the creation of all of its objects and it seems to me kind of wasteful.