ps：这篇文章发出来必然会被喷，但是我还是发出来了，有些话真是不吐不快
这几天又看了不少 MVP 的文章，真是千人千面啊，现在的 MVP 被大家玩坏了，什么样的 MVP 模式都有啊~
还记得当初 MVP 的出现为什么广受欢迎吗，还不是因为 Activity 被我们写的太重了，太难看了，太乱了。遥记当年，简单经过几个版本之后 MainActivity 我就写到了 2200行，不说公司里的其他小伙伴，即便是我想理清楚期中关节都不容易，代码很难维护。而 MVP 的出现则带来了曙光，从此 Activity 变得清爽了，因为我们把代码移到 P 里面去啦，再然后 P 就经历了当年 V 的覆辙
尤其是有的小伙伴把 P 当做了万金油，P 在 N 多个页面之间复用，因为一开始的确是可以拿来直接就用，但是随着版本更新，产品天马行空般的想法，以前看着相似的页面越来越多的产生差异，甚至不同，这时候再回过头来看我们的 P，有的 P 里面代码，逻辑非常复杂，不亚于以前我们那 2200 行的 Activity，历史在这一刻又重复了
我不知道大家想过没有，为什么会这样呢，mvp 不应该让我们的代码更简洁吗，为什么核心页面的 P 越来越难维护呢，为什么小伙伴们都不愿意接手我的代码，我也不愿意接手别人的代码，因为我们心里知道我的彻底的看一遍，要不真玩不转...
还记得这张图嘛
我们最早学习 MVP 时都看过这样图，其实一开始这张图就告诉我们了，MVP 是种解耦，分层思想，而不是复用机制。当我们更多的把 P 当做数据，业务层面的复用机制时，P 的难用自然就随之而来
MVP 是指一个页面中：显示，数据，操作的分离，P 的职责是负责分层一个页面，而不是多个页面。若是多个页面大体可以使用一个 P 的话，其实 P 也不应该去做复用，这脱离了它的初衷，复用的是业务逻辑，而不是 P 本身，否则随着版本的变迁，当初看似相同的页面，大多数时候会产生相当多的差异，你若是在最初复用 P 的话，那就只能是在这个 P 里不同的根据不同的页面页面添加不同的逻辑代码，这些代码相互交织，很容易出 bug，也变得越来越难以理解，除非你再拆分这个 P
MVP 应该是什么样子的
有句调侃的话：有一千个人就会有一千种 MVP ，我想大家都听过吧，这其实说明我们最初都没有真正理解 MVP 的设计初衷。
JAVA OOP 里面有个指导思想：单一职责，这里其实可以套用到 MVP 身上，是对一个页面的分层，而不是多个，V 和 P 应该是一一对应的关系，有一个 V 就应该有一个 P 与之对应
所以那些 P 对应多个 V，V 对应多个 P 的其实在分层的角度来看都是不恰当的。我们不是在写功能模块，比如地图，我们抽象核心接口，然后多态切换不同厂商实现，也不是写数据模块，同样的 repositroy 给不同的业务模块复用
UI 不同于功能实现，因为其显示复杂性，造成代码过多，不利于维护，我们才使用 MVP 思路来分层剥离实现，以达到便于维护的目的，是种结构层次上的优化，剥离出来的角色是一一对应的关系，拿来做复用其实是没理解 MVP 本身
这好比，以前我们都是一坨史莱姆，所有的都揉在一块，使用 MVP 模板让我们变成了人，产生了专门负责一种功能的器官，手就是拿东西的，脚即使用来走路的，最就是用来吃东西的，这让我们从一团混沌变得清晰。这时候你说多个人之间可以复用同一双手，人和人最初可能相同，但是随着时间人和人之间会产生差异，A 是搬砖的，A 的手就会变得粗糙；B 是做大保健的，B 的手变得柔顺灵活；C 是打拳击的，C 的手孔武有力，你说要是 ABC 3人当初用的是同一双手，你说这时候这双手会变成什么样...
abstract class BaseActivity<V, P : BasePersenter<V>> : AppCompatActivity() {}
abstract class BasePersenter<V> {}
class MacActivity : BaseActivity<MacActivity, MacPersenter>() {}
class MacPersenter : BasePersenter<MacActivity>() {}
MVP 之间其实因为一一对应 的结构关系，没必要写一堆接口，针对那些可以服用的业务逻辑我们复用的心思打在 P 身上是不对的，推荐大家去看看 MVI
最后
最后我想说：严格的分层其实比复用要重要的多，严格的分层会让我们的代码一直让一查看，维护，虽说一上来可以能增加工作量，但是越往后优势越大。着眼于未来常常会加大我们当下的工作量，但是会让我们今后受益无穷
肯定会被喷，但是这就是我想说的，正确与否欢迎大家讨论，我的目的就是想让大家重新审视一下自己的代码
网友评论