MVP模式中为何使用Base View与Base Presenter？能否省略？

嘿，关于MVP模式里的Base View和Base Presenter，我给你唠唠实际开发里的情况~

一、能不能省略它们？ #

答案是：完全可以，但分场景。

如果你的项目是个小Demo、简单页面（比如只有一个列表页+详情页），直接写具体的LoginView、LoginPresenter就行，没必要搞基类——毕竟基类会增加一点点额外的抽象成本，小项目里反而显得冗余。

但如果是中大型项目，页面多、业务逻辑复杂，省略基类的话你会哭的：比如每个Presenter都要写一遍attachView()、detachView()来管理View引用，每个View都要重复实现showLoading()、hideLoading()、showError()这些通用方法，代码重复率会飙升，后期维护起来要改N个地方，简直是给自己挖坑。

所以总结：小项目可省，中大型项目不建议省——省了反而增加长期维护成本。

二、最初为啥要搞出Base View和Base Presenter？ #

说白了就是为了解决重复代码和架构混乱的问题，核心原因有这几个：

• 复用通用逻辑，减少重复代码
  你想啊，几乎所有Presenter都需要持有View的引用，还要在页面销毁时解绑防止内存泄漏；几乎所有View都需要处理加载状态、错误提示这些通用UI操作。把这些逻辑抽进BasePresenter和BaseView里，具体的子类只需要继承，不用每次都从零开始写，大大提升开发效率。

• 规范架构约束，保证一致性
  有了基类之后，相当于给整个团队定了个“规矩”：比如BaseView里规定所有View必须实现加载、错误提示的方法，新人接手时一看基类就知道每个页面该有哪些基础功能；BasePresenter统一管理View的生命周期，避免有人忘记解绑View导致内存泄漏。这样整个项目的MVP实现风格能保持一致，不会出现五花八门的写法。

• 抽象通用能力，聚焦业务逻辑
  基类把通用的、和业务无关的逻辑都处理了，具体的LoginPresenter只需要关注登录的业务逻辑（比如调用接口、校验参数），LoginView只需要关注登录页面的UI渲染，不用再操心“怎么绑定View”“怎么处理加载状态”这些通用问题，代码职责更清晰，也更容易维护。

内容的提问来源于stack exchange，提问作者Ashutosh