Question

As an experiment I’m trying to write a generic MVP framework.

I started with:

public interface IPresenter<TView> where TView: IView<IPresenter<...
{
    TView View { get; set;}
}

public interface IView<TPresenter> where TPresenter:IPresenter<IView<...
{
    TPresenter Presenter { get; set; }
}

Obviously this can’t work because the types of TView and TPresenter can’t be resolved. You’d be writing Type<Type<... forever. So my next attempt looked like this:

public interface IView<T> where T:IPresenter
{
    ...
}

public interface IView:IView<IPresenter>
{

}

public interface IPresenter<TView> where TView: IView
{
    ...
}

public interface IPresenter: IPresenter<IView>
{
    ...
}

This actually compiles and you can even inherit from these interfaces like so:

public class MyView : IView, IView<MyPresenter>
{
    ...
}

public class MyPresenter : IPresenter, IPresenter<MyView>
{
    ...
}

The problem is in the class definition you have to define any members declared in the generic type twice. Not ideal but it still compiles. The problem’s start creeping up when you actually try to access the members of a Presenter from a View or vice versa. You get an Ambiguous reference when you try to compile. Is there any way to avoid this double implementation of a member when you inherit from both interfaces? Is it even possible to resolve two mutually dependent generic types at compile time?

Answer 1

I think the problem here is that you shouldn’t need both the IView and IPresenter interfaces to be generic – in an MVP framework either the view should call the presenter directly to drive the form (in which case the view should be generic for some presenter type) or the view should be totally unaware of the presenter and communicate through events (in which case the presenter should be generic for a particular view type).