pedrovgs/MVP_discussion.md

## MVP_discussion.md

      
    Raw
  

              MVP_discussion.md
            
          
    ##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).