笔者在研究 MVP 模式的时候查阅过相当多的资料,其中有两句话令我相当的深刻。一是:使用 MVP 模式虽然代码量会大大增加,但是为了降低耦合和逻辑上的简洁这个牺牲是值得的。二是:有些公司是根据代码量来统计工资的,所以使用 MVP 模式对于那些用代码量来统计工资的开发者来说,这应该是一个优点(然而,我们公司的工资和代码量时无关)。我当初就是信了你们的邪,当项目达到一定的程度的时候如果采用网上推荐的方式,重复的代码多到你无法想象好吗?每个 Presenter 都要处理大量重复的逻辑,项目中存在无数个功能相同的 Model(向服务器发起请求和发送回调数据到 Presenter)例如进度条的显示等等。不过当笔者意识到这个问题后,就通过泛型和封装优化了代码,解决了上述的问题,所以就有了前面的四篇文章。但是有一个问题是没办法通过优化代码解决的,那就是 Presenter 的管理问题。