I'm facing some issues related to code duplication when following MVP architectural pattern in an Android project that I'm working with. My project structure is separated by packages: data, domain, infra, ui. Inside ui package there are another packages for each screen of the app. Most of them contains this structure:

  • Contract: contains two interfaces, one for the view and another for the presenter;
  • Activity: which inherits view interface and implements some methods;
  • Presenter: contains very little business rules and communicates with my model;

I have another two interfaces (BaseView and BasePresenter) for the minimum of a View and a Presenter needs to implement.

Some of my screens has so much common code. They differ basically in layout and some specifics. This behavior occurs due to adoption of MVP rules (each view has its presenter).

I have found two answers for this issue on SO:

One suggests the creation of a base presenter class with common methods or an abstract class and the other accepts how the things are. I'm going to implement the base presenter or the abstract class, which leads to my question:

Based on the mentioned structure how can I achieve a good result without affecting or hurts a little this structure? Do I create a new package for this abstract class or base presenter? I believe this approach dirts the whole structure. So, what do I need to do?

  • You can create a base class for some presenters (as required), or you can create a completely different class and forward the actual logic to it, or you can even share a presenter between two closely related views - MVP in itself doesn't prevent that (depending the nature of the views, this may or may not be a good idea). As for whether to put that code in a separate package - that's more or less up to you, but keep in mind that these are the internal implementation details of the presentation layer, and so are a part of it. Nov 23 '17 at 15:42
  • @FilipMilovanović The last line of your answer is that concerns me a lot. You got the point. This is the exact point I believe that dirts structure. just because these are internal implementaion details of the presentation layer. Even it's up to me create a separated package with a presenter doesn't sound strange?
    – learner
    Nov 23 '17 at 15:49

MVP is architectural, and base classes, abstract classes, those are language-specific details of your implementation.

MVP is only about separating the M, V, and P. It doesn't really address the code reuse, which varies depending on implementation.

Probably the best answer here is to use a base presenter class to keep your helper methods. But you could also have a Helper class that holds that logic; which is better depends on if you're building out your own heavyweight framework, or just making a single lightweight app. In a single app, you probably only need one base presenter class. If you're building a framework, you need another layer of separation inside of the P layer to keep the Helpers.


Common logic almost necessarily deals with similar if not identical events, (sub-)views, and (sub-)models. Why not wrap this logic up and provide it with suitably adapted collaborators?

If the presenter accepted an instance of this behaviour, it could be configured with behaviour specific information, or even swapped out for alternate behaviour where you want it to differ.

No need to stop at one such piece either: a behaviour handling window sizing/minimisation, a behaviour for handling cancellation, a behaviour for handling xyz, etc...

The behaviours don't have to be a single action on an event (although that is essentially MVC old school), but neither do they have to deal with the whole view just the cohesive set of behaviours that are always present together.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.