##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).
I know that I am late but I want to give my opinion because this is the internet.
I totally disagree. I dont get the "confusing" part of an interface, it is a contract, an abstraction, even interface code as a POJO (talking about Java) can be transpiled to any language, it is pretty simple, there is no internal knowledge, can be used as a POXX (POCO, POJO, PONSO, even a C struct, whatever domain model or "plain old X object")
That's the magic of the interfaces, not
"being able to mock them"
, for the mocking framework it is the same if it is a class or an interface or even an enum (if you are on Java).Of course you will probably not get a second implementation of a Presenter or View, or any type of class, Service, Repository, or
any fancy name for your objects
here living in the same runtime as other, but you can still create a _StubPresenter_ in order to return real values to your application, this lovely _StubPresenter_ can be returned in your UI testing instead of the real implementation, just use the Stub and develop quickly and have faster tests instead of hitting your real implementation (flaky tests, anyone?).I remember now that I answered over the article discussion: http://blog.karumi.com/interfaces-for-presenters-in-mvp-are-a-waste-of-time/
back in the day of publication, this was my original answer:
I still hold that answer, I would leave the interface all days, everyday.
I also read this thread: https://www.novoda.com/blog/better-class-naming/ some time ago and I dont agree with that too,
Impl
is the name thatIntelliJ
provides for default implementations it is not a"naming convention"
just lazy developers who did not want to modify the default name and create a fast implementation using the magic of IntelliJ -> "alt/option/ctrl + enter"Just name it... I dont know,
ConcreteInterface
orAndroidInterface
orPlatformBeingUsedInterface
or leave the Impl, there is nothing wrong with that.Also... _we should not care about the concrete class names, the contract that we expose is what we care about!!!_
Also, if you program based on the interface, that contains the "good" name (based on the article), you dont care about the implementation, we should not care about the implementation, I dont care about logic of the Presenter if I am doing View logic, you care about the contract, if it says: "presenter.doSave()"... you know that you will save data, you dont care if it will be slow, fast or if it is really going to go to a database or if it is an empty subroutine, you know that it will call the save subroutine and if it is empty that's okay, you are hitting the presenter, your layer should not care about what will the next object/layer do, only its responsibility.
Sorry for reviving this thread I saw a question over this tweet:
https://twitter.com/donnfelker/status/788842213283274752
and an answer: https://twitter.com/Guardiola31337/status/788846661791547392 with a link to this discussion! :P
PS: if you really do TDD (tbh I dont.), just create the contract and then you will just following the contract, mock the interface and everything is going to be created progressively, you will create the test case for the user of the contract, then you will create the test for the implementation of the contract and mock any dependency using just an interface, you will not care about code. Even for lazy programmers that dont want to write a lot... it is even simpler to create an interface:
even if we go and compare workflows with shortcuts it is simpler to create the interface!! haha.
this would be my workflow in macOS and IntelliJ/Android Studio when doing some TDD:
cmd+1
cmd+n
class
cmd-[
(back in IntelliJ)Come on, compared to:
cmd+1
cmd+n
class
{}
or{ return null }
cmd-[
(back in IntelliJ)BTW: I love this kind of conversations over internet, please invite me :(
tl;dr in english:
to be honest, I would leave the interface, I dont see the "noise" on using a contract instead of a concrete class, if you use a simple text editor it is not an excuse to say: "that's noise" because you would see (probably because everyone else that is not a super hackyhackerhackman uses Android Studio or IntelliJ while doing Java) the same contract name and the suffix
Impl
or if you are not lazy justConcreteInterfaceName
orAndroidInterfaceName
(or I prefix if you do C#), you would only go to the interface if you are looking for the contract."the tl;dr is tl;dr": https://en.wikipedia.org/wiki/Dependency_inversion_principle
tl;dr in spanish:
La neta, yo dejaria la interfaz, no veo el "ruido" en tener un contrato simple en lugar de una clase concreta. No es excusa tampoco que usas un editor de texto basico y que "confunde" por que verias el nombre del archivo seguido de "Impl" (por que todo mundo que no es un super hackity hack man usa IntelliJ o Android Studio) ó cualquier nombre como
AndroidInterfaceAqui
óInterfazConcretaAqui
ó el prefijo "IInterface" si usas C#... solamente irias a la interface si buscas el contrato."el tl;dr es tl;dr": https://en.wikipedia.org/wiki/Dependency_inversion_principle