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