有过接口化编程经验的人应当知道，接口化可以实现功能和模块的插拔，当项目变大，客户，业务，版本出现多个不同分支的需求时，接口化的代码，只要替换一个实现类，就可以在不改变旧代码的情况下，应对需求的变更。
完整的MVP模式，应当也是接口化的，Activity和Presenter可以随意替换，甚至Activity可以任意组合多个Presenter。
但是对于初级开发人员，或者中小应用来说，可能代码不多，业务情况也是固定的，大多接口可能永远只有一个实现类，抽离出接口的意义不大。这种情况下，使用上篇文章中提到的简化模式就已经足够了。确实有需要时，再抽离一个接口也不迟。
上篇文章已经讲解了，相比传统代码，MVP将View-Controller，View-Model分离带来的好处。这篇文章讲解MVP的完整形式，和接口化的作用。 
如上所示，现在的代码和之前的区别在于，LoginActivity和LoginPresenter并不直接发生联系，而是分别实现了一个接口，通过接口互相调用。这样（接口化）的好处在于：
- 当出现新的登录业务时，不需要需改LoginPresenterA的代码，只需要创建一个LoginPresenterB，实现ILoginPresenter接口，让LoginActivity中的presenter = new LoginPresenterB(ctx)即可。旧代码基本没有变化，只需修改一行实例化代码，就能任意在A业务和B业务之间切换。
- 当需要新的登录界面时，不需要修改LoginActivityA的代码，只需要创建一个LoginActivityB，实现ILoginActivity接口，这时Presenter持有的就是LoginActivityB的类实例。不需要修改任何旧代码，就能切换到新的界面。
- 当接口存在A和B，甚至更多的实现类，并且在实际工程中，需要频繁替换的时候，接口化的优势尤其明显。如果不使用接口，而是在同一个文件中，将A业务代码注释或修改掉，替换为B业务的代码，再将B业务的代码注释或修改掉，替换为C业务的代码，不但工作量大，且容易造成混乱和错误。
- 有的人喜欢创建PresenterA和PresenterB两个具有一样方法的类，而不实现接口，也可以实现一样的效果，这实际上是一种不规范的隐性接口化。
