最近打算写一个“纯正”的 MVP 程序，结果发现越搞越复杂，发现很容易陷入 Presenter 滥用的陷阱。今天清理一下思路，写个小总结。
1. Presenter 必须访问 Model
一个合理的调用流程应该是 A-B-C-D，或者 A-B-C，或者A-B。也就是说，View 需要访问 Model 时，才需要向 Presenter。如果不需要访问 Model， 则完全不必访问 Presenter。例如，流程 A-D 纯属脱裤子放屁，多此一举。
因此，Presenter 中的所有方法，都是需要访问 Model 的，如果不需要访问 Model，该方法则是冗余的。因此，合理的调用过程必须包含步骤 A-B。
考虑到 Presenter 中可能存在工作线程，B-C-D 的调用过程应该是合理的。
| 调用过程 | 合理性 |
|---|---|
| A-B | ok |
| A-B-C | ok |
| A-B-C-D | ok |
| B-C-D | ok |
| A-D | x |
| D | x |
2. IView 接口尽量简单化
View 自己能处理的事情，尽量不要通过 D 来调用 IView，绕一圈子再回来处理。
先写这么多，等我完成手头的任务，再写一份详尽的总结。，手头的代码需要重构一下了。
3. 简化 Presenter 和 IView 的好处
简化 Presenter 和 IView，能使的系统设计更容易适应需求的变化。事实上，系统结构越复杂，软件设计就越具象化，就越难适应需求的变化。
4.一点思考
以前读过一篇文章说，Presenter 的接口方法一定是 void onXXXX() 的形式，不需要返回任何错误信息。其实这样做很荒唐，如果不能返回信息，必然造成需要 Presenter 通过 IView 接口调用 View 的方法显示错误信息，严重增加系统的复杂性。
我觉得 Presenter 的方法如果能返回错误信息，能明显简化系统逻辑关系。
