MVP With Better Naming of implementation classes & DRY Principle

Nowadays MVP is a very trending topic in android community. But No matter how many advantages it offers, we doomed with bad naming of our classes. And further more very hard to traverse through code!

But recently i read this nice article which helped me to make my code look better and make my client happy too :) But i want to extend Paul Blundell’s article and want to present a beautiful naming of classes and plus refactoring the common code we usually implement in most activities.

When we implement MVP in our code we mostly see some operation is very common and they being replicated in each screen like isInternetAvailable(), showProgressDialog(), dismissProgressDialog etc. This is very bad!

It violates the rule of DRY (Dont Repeat Yourself )

In our software a piece of knowledge should be in one single location.

So I had extracted all the method which are getting duplicated in each activity, each presenter and each Model in their unique parent interface and called it Mvp Interface. And this is what my base MVP interface looks like:-

Base Mvp model, view, and presenter interfaces

So now our Mvp interface contains all the common methods in its view, presenter and model interface. So we have saved lots of boilerplate code and followed the DRY practice very nicely:)

Then we can make the Login interface/contracts which extends the Mvp Interface to use the common functionalities defined. And this is Login Interface looks like:

Login Contract

Now we don’t need to use LoginPresenterImpl Or SimpleLoginPresenter Or DefaultLoginPresenter but simply we can define LoginPresenter.java!

Never Use Impl/Simple/Default as prefix/suffix for our classes!

I can then just implement the LoginModel class and LoginPresenter class to implement my model and presenter functionality related to login!

And this is how we have better naming of MVP related classes!

Also I am using MVP in many projects and its easy to test and helps to decouple UI, Model and make methods smaller, but when app getting bigger its hard to go all over the code cause so many views presenter all becoming mess gradually.

And finally it became necessary to think about how to restructure our app so it gets easy to move around the code for doing real work! I think its better to use package for domain rather than common naming like (activities, fragments, dialogs, services,etc) which becomes tough when app getting bigger!

We should make package for each domain specific thing like if we have LoginActivity, LoginPresenter, LoginModel, LoginView then we should name the package Login as it serves the purpose of login the user!and we should move them into that domain centric login package, so it will be easy to find the classes.

MVP package structure

This package structure gives the developer very effective way to traverse through code. This structure helps to group the classes for same concept.

So the package becomes a group of classes which works with each other to serve the single goal!

This gives the developer very easy and sneak view of app functionality too in a single moment of sight!

If you found this article helpful, please do hit the heart button below and let me know on Twitter.

Let’s get connect on facebook, twitter, github and linkedin.

Thanks!