前言
这里不在介绍MVP模式的概念。只讲一些自己开发中对MVP模式的体会,和一个Activity多个Fragment场景下MVP的应用,和需要注意的问题。
注意问题
【1】首先第一点,无论是什么模式,你都需要贯彻面向接口化编程的思想 ——–M, V,P三层之间都通过Interface实现依赖,这是实现解耦最简单的办法。
【2】MVP的设计思想除了解耦意外,还要实现的一个目的是稳定和复用。(在V很容易变化的环境下实现项目的稳定和P的复用)
所以除了保证接口的稳定意外,还要保证P的健壮。并实现P的复用(我理解P的复用,不是指多个V公用一个P,当然这是要尽力设计的方向之一。而是指“无论V如何变化,P是保证不变的”)
那么依照这个思路,P就不能包含过多的业务逻辑,业务的需求是多变的。保证经过P的方法是可测的(明确的输入输出)
【3】MVP是一个沙漏状的模型。 V和M很多很大,随着需求的改变很容易变化。他们通过一个窄的桥 P 沟通。
问题1:通常一个P对应一个V(一对一的修改勉强可以容忍),但是N个P会使用一种M。那么需要考虑如何解决将来有可能的问题: 因为一个M的修改导致要查找修改N个P。
这时就体现出接口调用的重要性了,确保接口的稳定性就没有问题,必要时可以采用工厂模式
问题2:Demo里,通常都是1个V—1个P—1个M。但是实际需求中,P肯定不止使用一个M。当一个P里放着六七个M的接口引用,并且要new或create的时候就感觉挺不舒服了。
如果业务逻辑真的很复杂的话,这