##Interfaces for presenters in MVP are a waste of time!
It's been a long time since we started talking about MVP. Today, the discussion is about if creating an interface for the Presenter in MVP is needed.
This is the Model View Presenter pattern's schema:
In this schema the Model box is related to all the code needed to implement your business logic, the presenter is the class implementing the presentation logic and the view is an interface created to abstract the view implementation.
Why the view should be implemented with an interface in this pattern? Because we want to decouple the code from the view implementation. We want to abstract the framework used to write our presentation layer independently of any external dependency. We want to be able to change the view implementation easily if needed. We want to follow the dependency rule and to improve unit testability. Remember that to follow the dependency rule high level concepts like the presenter implementation can't depend on low level details like the view implementation.
Why the interface is needed to improve unit testability? Because to write a unit test all the code should be related to your domain and no external systems as a SDK or a framework.
Let's go to put an example related to a login screen implemented for Android:
/**
* Login use case. Given an email and password executes the login process.
*/
public class Login {
private LoginService loginService;
public Login(LoginService loginService) {
this.loginService = loginService;
}
public void performLogin(String email, String password, LoginCallback callback) {
boolean loginSuccess = loginService.performLogin(email, password);
if (loginSuccess) {
callback.onLoginSuccess();
} else {
callback.onLoginError();
}
}
}
/**
* LoginPresenter, where the presentation logic related to the login user interface is implemented.
*/
public class LoginPresenter {
private LoginView view;
private Login login;
public LoginPresenter(LoginView view, Login login) {
this.view = view;
this.login = login;
}
public void onLoginButtonPressed(String email, String password) {
if (!areUserCredentialsValid(email, password)) {
view.showInvalidCredentialsMessage();
return;
}
login.performLogin(email, password, new LoginCallback {
void onLoginSuccess() {
view.showLoginSuccessMessage();
}
void onLoginError() {
view.showNetworkErrorMessage();
}
});
}
}
/**
* Declares what the presenter can do with the view without generating coupling to the view implementation details.
*/
public interface LoginView {
void showLoginSuccessMessage()
void showInvalidCredentialsMessage()
void showNetworkErrorMessage()
}
public class LoginActivity extends Activity implements LoginView {
.........
}
Please don't pay attention to the code syntax. I've written this from the scratch and it's almost pseudocode.
Why the View interface is needed here? To be able to write a unit test replacing the view implementation with a test double. Why is this needed in the unit test context? Because you don't want to mock the Android SDK and use the LoginActivity inside your unit tests. Remember that if you write a tets where the Android SDK is part of the SUT this is not a unit test.
At this part of the implementation is clear. We need an interface to do not depend on the view implementation.
Some developers have decided to add also an interface in top of the presenter. If we follow the previous example the implementation could be like this:
public interface LoginPresenter {
void onLoginButtonPressed(String email, String password);
}
public class LoginPresenterImpl implements LoginPresenter {
....
}
or
public interface ILoginPresenter {
void onLoginButtonPressed(String email, String password);
}
public class LoginPresenter implements ILoginPresenter {
....
}
What's the problem with this extra interface? IMHO this interface is not needed and is just adding complexity and noise to the development. Why?
- Look at the class name. When the interface is not needed the names used become weird and don't add semantic to the code.
- That interface is the class we have to modify to add a new method when the presentation logic has a new path and then we have to also update the implementation. Even when we use modern IDEs this is a waste of time.
- The navigation in the code could be difficult to follow because when you are inside the Activity (the view implementation) and you want to navigate to the presenter the file where you are going to go next is the interface when most of the time you want to go to the implementation.
- The interface is not improving the project testability. The presenter class can be easily replaced with a test double using any mocking library or any hand made test doubles. We don't want to write a test using the activity as SUT and replacing the presenter with a test double.
So...what is the LoginPresenter interface adding here? Just noise :)
But.....when should we use an interface? Interfaces should be used when we have more than one implementation (In this case the presenter implementation is just one) or if we need to create a strong boundary between our code and a third party component like a framewokr or a SDK. Even without interfaces we could use composition to generate abstraction, but the usage of an interface in Java is easier :) So, if you have more than one implementation of the same thing or you want to generate a strong boundary, then, add an interface. If not.....do not add more code. Remember, the less code to maintain the better. Remember that the usage of interfaces is not the only way to decouple our code and generate abstraction
But...what if I want to decouple the view implementation from the presenter implementation? You don't need to do that. The view implementation is a low level detail and the presenter imlementation is a high level abstraction. Implementation details can be coupled to high level abstractions. You want to abstract your domain model from the framework where it's executed, but you don't want to abstract in the opposite direction. Trying to reduce the coupling between the view implementation and the presenter is just a waste of time.
I've created this gist to discuss about this topic, please feel free to add any comment using code examples if needed :)
Extra ball: If you are thinking in different testing strategies for Android and the presentation layer I wouldn't use a unit test to test the presentation logic replacing the view with a test double. I'd try to use an approach like the one described here where the SUT is the whole presentation layer and not just the presenter (the test doubles are used to replace the use case).
vayamos por partes, porque me parece un discusión un poco absurda. Hablamos de que utilizamos un interfaz para crear un contrato, que que queremos que varias clases implementen, para poder depender de una abstracción y no de la implementación concreta, espero que hasta aquí estemos todos de acuerdo.
Luego una de las reglas del buen diseño de software dice: Has few elements. Por lo cual si tenemos solo una implementación del contrato podemos destacar que no hace falta tener un interfaz con con el contrato porque está explícito en la definción de la clase a traves de sus métodos públicos.
En el hipotético caso que te haga falta una segunda implementación de esa clase con código distinto, pues nada más fácil que extraer el interfaz y depender de esta nueva abstracción, para los que os mole AndroidStudio, os lo hace con un click ;)
Estas reglas no son solo para los presenters, si no para la construcción de cualquier software. No escribias código de más. Hay que escribir el mínimo código que esté bien y responda a nuestro problema. Claramente en el caso de un presenter que solo tiene una implementación, no tiene ningún sentido crear un interfaz. Si me decís que lo haces por motivos de testing, recordar que debemos evitar a menos que sea imposible hacerlo, crear código solo para tests ;).
Esa es mi opinión y espero haber echado luz al asunto.