##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).
Llego muy tarde, pero me da igual, yo pongo mi comment!
Disclaimer: Esto lo digo a toro pasado, con lo cuál no tengo mérito ninguno chavales, peeeero ahí voy igualmente! 💃 😄
Bajo mi punto de vista, en el caso de Java (no tengo intención de entrar en otros lenguajes), una interfaz existe para abstraer un comportamiento / contrato que vas a necesitar implementar por diferentes clases. Por tanto considero que pierde su valor si partimos de una implementación que siempre va a ser única. Aquí podríamos pensar que ojo, ¿y si mi implementación es única en el código de producción pero tengo una segunda implementación fake de cara a los test? Honestamente, yo sacaría esa implementación de esta disusión, y más abajo explicaré por qué. Así que para sintetizar, usaría una interfaz si los requisitos de mi producto me están pidiendo varias implementaciones diferentes a lo largo del código de producción de mi aplicación.
Sample: Imaginemos un par de implementaciones diferentes del mismo presenter porque mi view es capaz de funcionar bajo 2 modos diferentes de presentación. Un ejemplo que hice yo mismo en JT:
PostJobPresenter
gestiona la lógica de presentación para postear un nuevo job, pero tiene 2 modos de uso. Puede servir tanto para editar un job ya existente como para postear uno nuevo, con los cambios de comportamiento en la vista y el dominio que eso supone. (Que los hay). De esta manera evito tener un súper presenter con muchas líneas que sepa manejar ambas situaciones, y lo que hago es switchear dos implementaciones diferentes dependiendo de si el tío viene navegando desde un botón de edición o desde el FAB para publicar un job nuevo.Inciso de bullshit: Mucha gente tiene su punto de vista algo viciado porque piensa que con Dagger o cualquier otro framework de DI sólo podemos inyectar dependencias partiendo de interfaces, lo cuál sabemos que no es cierto.
Más cositas: El caso de empresas (como el que describe @txusballesteros) que necesitan trabajar en paralelo en la vista y el presenter es necesario establecer un "contrato" a seguir que sea común, y es cierto que para ello son útiles. Pero como bien explicaba @davideme, puedes lograrlo creando una implementación early de tu clase concreta, en este caso del presenter, trabajando ambas partes a partir de ese nexo. Habiendo pensado un poco sobre el tema, y tras haber discutido esta forma de trabajar más de una vez en mi empresa, yo prefiero este approach en lugar de meter sin más una interfaz, que al final es una clase adicional no necesaria dentro de tu código.
Y para terminar, como decía antes, yo intentaría mantener el tema testing un poco al margen de usar o no interfaces, porque al fin y al cabo para mí tiene poco que ver. Lo que marca el hecho de poder aislar el SUT e introducir test doubles en los huecos abiertos para sus colaboradores, es que sus dependencias estén inyectadas (independientemente de si son abstractas o directamente concreciones, y si están inyectadas a partir del constructor, setters, fields, o con un framework que te inyecta código en tus .class rollo lombok y te resuelve las dependencias en tiempo de compilación). De este modo, podrás inyectarle en tiempo de testing una implementación / extensión diferente. Recordad que los test doubles se pueden crear por extensión, ya que nuestras clases concretas también tienen un contrato expuesto hacia fuera con sus métodos y fields públicos (incluso package visibility), con lo que siempre podrás overridearlos y alterar su comportamiento. Por tanto, si yo tuviera que mockear mi presenter (aunque no sea una práctica común si testeas la vista, ya que acaba siendo un test muy end to end) lo que haría sería inyectar en tiempo de testing una extensión del mismo redefininendo los métodos públicos que son los que exponen hacia la vista el contrato de uso.
El punto de vista de la encapsulación de infromación, exposición, visibilidad etc, es muy importante cuando creas librerías o cualquier tipo de código para terceros y tienes que tener en cuenta la facilidad de uso de puertas para fuera.