6

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?

Improve this question
2
  • 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ć
    Commented Nov 23, 2017 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
    Commented Nov 23, 2017 at 15:49

3 Answers 3

Reset to default
1

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.

Improve this answer
1

Prefer composition to inheritance. Why? Gives you more control. A base class just saves you some keyboard typing. But it locks in many assumptions that now have to hold true for the life of the project. Composition lets you hide more details and so gives you more freedom to change them later with little impact.

Remember, an architectural layer is allowed to have more than one kind of object in it. Don't confuse the job to be done with what things need to be.

Improve this answer
1
  • For example, UI objects can start with a system provided class, then make a subclass with optional callback members that are called if not null at the right times, and then you have a factory class, retuning an instance of the subclass, with the right callbacks set. Or instances of other classes set. So all your code works with instances of the same subclass. Possibly without exposing that they belong to a subclass.
    – gnasher729
    Commented Feb 11, 2023 at 20:26
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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