Is there any best practice for packaging MVP layers?

I have done some Android applications using MVP methodology,

But I am not so sure if it is better to place different layers objects of the same feature in a same package? or package all layers items of different features in the same package with layer name on it?

(Which I mean something like this)

Currently, I am following the second rule, but is this the best practice?

Edit: This is my project's whole packages! :)

4 Answers

Just to throw my thoughts into the mix. I have worked on projects with each of these approaches. My preference now is to package by feature. There are two main reasons I prefer this approach:

Ease of Induction

Increased visibility of project structure for developers new to the codebase. When classes which relate to a single feature are grouped together it is much easier for a new team member to quickly see how everything fits together.

Restricting Class access

This is probably more important. When you package by type (all Presenters together, etc) you have to give many methods in these classes public access. This can lead to these functions being used inappropriately from various areas of the codebase.

If you package by feature then these classes are all in the same package and as such you can give the methods package level access. This ensures that methods don't leak.

Create a feature-specific package which contains a Contract interface containing the View and Presenter interfaces. The feature package also contains implementations of the View and Presenter interfaces (i.e. the Activity and Presenter classes).

I have made a sample project here; you may refer it for more info on MVP.

You should create separate package for base MVP classes and package for each MVP - entity. Say, 'mvp_base' for basic stuff and 'some_screen' package, inside which you'll be having your Activity, Fragments, etc. Concrete mvp implementation for 'some screen' put in 'mvp' package inside 'some_screen' package. It is also a good idea to store all your models and presenter inside Service and bind to it upon UI creation.

I prefer this packaging model in main package:

• Common classes take place in main.

• Every package is a feature of app or a layer of app.

• Data: Data Layer. Contains classes which use for data. For example domain classes, repository classes, data source classes etc.

• If you design Mvp - Clean architecture and do your business in Interactor classes. (or Use-Case classes) you can create a domain package in related feature and put them this location.

• Util contains util classes.

• View and presenters get defined in a class called Contract.

Here is an example of Contract class:

interface SupportContract { interface View extends BaseView { void showTenthChar(char c); void showEveryTenthChar(@NonNull char[] chars); void showEveryWordWithCount(@NonNull HashMap<String, Integer> data); } interface Presenter extends BasePresenter<View> { void onSupportDataRequested(); } } 

According to me the main benefit of this model is someone when see the package model can easily understand the layers, features and requirements of app.