我看了谷歌的MVP案例之后，在项目中套用也使用了MVP，但是，随着界面的增多，请求数据的增多，出现了一个问题，就是接口类的数量成倍增长，并且V层中需要实现的接口增多很多。
我在网上看到的好多MVP使用讲解，都是单单一个界面，一个请求，一个V只对应一个P。
但是我在开发的时候想，其实很多界面中的部分请求很可能都是相同的，或者说是属于同一个模块的，所以我改成了将同一个模块的请求放在了一个专门的P类中了。
另外，对于数据回调用的接口，项目写了没多少就发现增加了很多很多，并且接口中又是基本的onSuccess,onError,onFinish这些方法，V层每需要请求一种数据，都要增加三个这类的方法，因为要区别数据结果，这样V层的方法也增多了很多。这时候我就改了另一种方法，只用一个接口，参照onActivityResult的方法，请求数据的时候，带上一个参照值，P类对数据获取的状态进行判断，然后将状态、参照值和结果（放在一个能放多种类型数据的容器）一并返回，这样就免掉了很多的接口。
虽然我换了一种方式，但是不知道是否违背了MVP的初衷。请问有什么好的解决方案吗
http://www.cnblogs.com/liuling/archive/2015/12/23/mvp-pattern-android.html
MVP的初衷就是为了让Presenter接口负责完成View于Model间的交互,完成model和view的解耦。按照我的理解,你这样做没什么问题,只是如果需求变了,请求不同的时候,要修改对应Presenter的时候有点麻烦.
如果项目比较大，一定会造成P和view里近百个文件。推荐下列方式：
app
config
model
entities
module——将界面层以功能模块分配包。
launch
main
account
news
music
……
utils
widget
app
config
model
-----entities
module——将界面层以功能模块分配包。
-----launch
-----main
-----account
-----news
-----music
-----……
utils
widget