Interface explosion problem

Question

I am implementing a screen using MVP pattern, with more feature added to the screen, I am adding more and more methods to the IScreen/IPresenter interface, hence, the IScreen/IPresenter interface is becoming bigger and bigger, what should I do to cope with this situation?

Answer 1

Can you break your interface into sub-interfaces representing sections of the screen? For example, if your screen is divided into groups such as a navigation section, or a form section, or a toolbar section, then your IPresenter/IScreen could have getters for interfaces for those sections, and those sections could contain relevant methods for each section. Your main IPresenter/IScreen would still have methods that are relevant to the whole interface.

If sections of the screen don't work as a logical category for your application, think of other things that might provide a logical breakdown. Workflow would be one.

EDIT For example:

For example, for a large UI which I did, I actually broke up not just my presenter but also my model and view code. The entire screen neatly broke up into a tree (in this case), with the main presenter delegating work to the children presenters and down the chain. When I had to later go back and add to this UI, I found fitting into the hierarchy fairly simple and maintainable.

In an example that works like this, the MainPresenter implementation of IMainPresenter knows about both it's model, it's view, and it's sub-presenters. Each SubPresenter controls its own view and model. Any operations on what logically belongs in that sub-section should be in the SubPresenter. If your screen is laid out in such a way that there are logical units like this, such a set-up should work well. Each SubPresenter should be able to return its SubView for the MainPresenter to plug into the MainView as appropriate.

Answer 2

In my opinion, a "perfect program world" contains public interfaces and internal implementations.

Each interface is strictly "in charge" of one thing only.

I try to view these entities is "little" human beings which interact with one another in order to complete a certain task.

(sorry if this is a bit of philosophizing)

Answer 3

What flavor of Model-View-Presenter are you using? I've found that Passive View rarely involves overlap between the view and presenter interfaces - normally they change at different times.

Typically the view's interface is essentially a view model, perhaps something like this (C#-style):

public interface IEditCustomerView {
    string FirstName { get; set; }
    string LastName  { get; set; }
    string Country   { get; set; }
    List<Country> AvailableCountries { get; set; }
    // etc.
}

The view implementation usually has handlers for user gestures that are usually thin wrappers that call into the presenter:

public class EditCustomerView {
    // The save button's 'click' observer
    protected void SaveCustomer() {
       this.presenter.SaveCustomer();
    }
}

The presenter generally has a method for each user gesture, but none of the data, since it gets that directly from the view (which is generally passed to the presenter in the constructor, though you can pass it on each method call if it's more suitable):

public interface IEditCustomerPresenter {
    void Load();
    void SaveCustomer();
}