mvp思考

mvp用了很久了，在多个项目中使用到了它，也给几个项目做过改版，突然觉得mvp很鸡肋

page你瞎扯，这么好的一种模式，怎么就鸡肋了？

首先，每一种模式都有适用的情景，一种模式想要更通用，那么只能不断变种。而mvp的变种，网上也有很多了，为了适应自己的项目，大家都以自己的风格改变了mvp的基本写法，
mvp最基础的思想：v层与m层分离，通过presenter层来交互。
于是，网上出现了很多以登录为例子的demo。
以这个例子为模版写了几个模块代码之后，感觉捉襟见肘，束手束脚，于是看了看谷歌的mvp demo。发现一个叫contact的东西，顿时发现，谷歌这种写法，颠覆了我的认知。
拜读了许久，发现，让我照着谷歌这样写，有点难受，不符合我的风格，虽然，它这样，非常棒。
不过，读它的代码，总是学到了什么，例如fragment。
fragment都能让你学到，page，你的基础不扎实啊！
咱透过现象看本质。
从fragment中，我学到了什么：封装，模块化。大概这样理解，只是我想到这两个词上去了。
page，说详细点啊，这样，别说我了，其他人也看不懂啊。
确实看不懂，我想到这两个词之后的一个念头就是，莫名其妙。封装和模块化，谁不懂？但凡接触编程超过四年(接触嘛，就是从学习开始)实际工作超过一年的朋友，哪个不懂面向过程，面向对象，不懂封装，不懂模块化，不懂组件？只是很少实践而已。
那么从这里，我看到了，把一个功能用一个fragment来代表的可能。
page你又说笑了，fragment出来不就是为了这个吗？而且都出来好久了。
是的，出来很久了，而且用得也不少，踩了很多坑。
可是，fragment+mvp却有许多需要考虑的地方，比如，presenter是放到fragment还是activity中？
如果是获取数据，当然还是根据业务服务来决定了，一般建议跟对应view一起考虑，例如，如果操作的是fragment中的view，那么，放入fragment中，如果操作的是activity中的view，例如toolbar中的确定，那么放入activity中，如果是获取数据，建议哪里需要这个数据，就在放到哪里。
为什么？
为了让fragment复用，虽然大多数情况，fragment无法复用，我一个项目中，也就只有两个地方复用了。毕竟，不建议重复功能入口，但是同一功能的不同表现形式，那就另说了，例如编辑文字和添加文字，这个由于业务服务不一样，但是对应ui接口一样，那么，fragment可以复用，presenter则放入各自的activity中
page，就编辑一行文字，用得着费劲这样做吗？
不不不，附带着获取推荐文字，输入辅助等，多种功能，so…..
说到复用，项目中有多个地方使用到了同一个业务，可是却是在不同界面，对应不同的ui操作。
说道这里，得先说说，关于view和model分离的两种流派，一种是仅仅分离，ui操作或者逻辑还是在activity中，所提供的接口，仅仅是model成功，失败方法，或者再加一个等待；还有一种，则是，所有的逻辑写在presenter中，这样，presenter调用界面的某一种变化，例如显示或隐藏。
在刚所说的场景中，很明显，适用于第一种流派，真不巧，公司大多数人都推崇第二种流派。
如果使用第二种，那么，p层和v层都需要重写，
如果使用第一种，那么，只需要重新v层实现.
针对这中情况，我和朋友们有过一次探讨，各执己见，各处不同角度，说不上谁好，谁坏，但都有一个共同点，只使用其中的一种流派，因为，如果同时使用两种，会增加阅读难度。
而后的一段日子，我都在想这个问题，问题的最优解没有找到，却想到了另一个问题。
v层和p层之间有接口，p层和m层之间有接口，屏蔽了内部实现，只开放了接口。
可是，这样有什么用？
我的某一个朋友，对此，大谈设计模式，几大原则。
然而，我却不认同，接口，屏蔽内部实现的目的是，不管内部怎么实现，也不管你到底有几种实现，可是，如果只有一种实现，那这个接口的意义还有吗？
有人说，为了扩展，为了以后的维护。
可是真的需要吗？

暂时写到这里，有空继续