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. – Filip Milovanović 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.

Your Answer

