C++ Model View Presenter: Where to construct presenter

dependency-injectionmvppresentation-model

I'm using the Model View Presenter (MVP) pattern as described in The Humble Dialog Box paper (pdf) with an MFC project. I'm sure the issue is the same with most GUI toolkits.

The thing that's bothering me is the concrete view (i.e., the dialog class) is creating not only the presenter but also the services that the presenter needs. Is that normal? Why does the view need to know what services the presenter needs? What I'm thinking is that I should dependency inject the presenter into the dialog class.

The main control for the application is a class derived from CWinApp. So should I construct services and presenter in this class and then inject them into the dialog class?

Although how would I dependency inject the presenter into the dialog class when the presenter needs a reference to the view class in it's constructor?

MyPresenter(IView *view, MyService *service);

Also how about if the main window spawns off a popup window, where should the details for that windows presenter and services get constructed?

Since this is C++ I don't think I'd be interested in any kind of DI framework.

UPDATE

One idea I had was to construct the presenter with a null view, constructor inject the presenter into the dialog class, and then in the constructor of the dialog class call a SetView(IView *view) method on the presenter with this where this would be the dialog class (which derives from IView). So:

MyApp::Start()
{
  SomeService *service = new SomeService();
  MyPresenter *presenter = new MyPresenter(null, service);
  MyDialog *dialog = new MyDialog(presenter);
  ...
}

MyDialog::MyDialog(MyPresenter *presenter):
 presenter_(presenter)
{
  presenter_->SetView(this);
}

Seems a little kludgy but keeps service construction out of the Dialog class. The null view seems a little dangerous. An alternative would be to actually construct a NullView class that had empty method bodies and then pass that into the presenter constructor.

Best Answer

Perhaps a better solution is to use a factory class or method that knows how to build a presenter? The view would pass itself to the factory method and store the return value in it's presenter member.

This decouples information about how a presenter is constructed (dependencies on services or whatever) from the view itself.

Related Solutions

Java Dependency Injection – Using Guice to Replace Service Locator Implementation

Both Game and WorldFactory class would have FileSystem as their dependencies. Below is an example of dependency injected through a constructor (it is also possible to inject them directly into fields):

@Inject
public Game(FileSystem fs) { }

@Inject
public WorldFactory(FileSystem fs) { }

You could then write a provider inside one of your modules that would construct and return a new FileSystem instance:

@Provides
FileSystem provideFileSystem() {
    return ServiceLocator.getService(FileSystem.class);
}

Once you treated other services similarly, you will be able to completely remove your reliance on ServiceLocator, moving the service-creating code directly into providers.

So then you get an odd instance where the constructor of a game entity requires that you pass an instance to the AudioSystem to it which it can play audio through. It just gets very messy with all these objects/services being explicitly passed around.

Not only this is not messy, this is the whole point of dependency injection. The thing is, however, that you should never explicitly pass all those instances manually. Instead, you can have Guice reconstruct the dependency graph from them and construct all necessary, intermediate objects (or obtain them in any other way you specify in your providers). On your side, creating the final object is just a matter of calling Injector.getInstance(Foo.class) -- it's up to Guice to figure out how to satisify the dependencies.

IoC Pattern – Using IoC as a Service Locator

Good Question!

When the service becomes complicated, the number of dependencies will grow more and more

In that case your dependencies are maybe not standalone dependencies but can be grouped into simple dependency-holding classes that can be used to pass into the constructor.

A good sign would be if more than one of your classes use both IRepositoryA an IRepositoryB in the constructor and also in some of their methods like in your SomeMethod1 method. You should be able to find a good name for the class that groups IRepositoryA and IRepositoryB. If not, consider going to tell us the real example so we can analyse better.

SomeMethod1() only uses repo A and B, but when client calls it, the service is created with all repositories, meaning it has more dependencies than it needs.

But that is okay because normally you want to make sure that at the time when the class is created you don't want the IRepositories to be changed anymore. They should be declared as immutable. That is a good practice.

If that's not the case and they shall be mutable, then you could make the IRepositoryC dependency beeing passed into SomeMethod2 as parameter. Currying / partial applying can help you to prevent code-duplication here when you call the method many times with the same IRepositoryC argument.

A different approach would be passing option-types into the constructor. Your class would then however have the responsibility to check in their methods if a given IRepository has already been provided or is still empty at the time of the method call.

So it depends a little on what you really want to do. There is imho no general answer to this problem.

Best Answer

Related Solutions

Java Dependency Injection – Using Guice to Replace Service Locator Implementation

IoC Pattern – Using IoC as a Service Locator

Related Topic