瞎扯

既然说到了MVVM,就再说说MVP.
已经是老生常谈了.
MVP的文章我写了有7 8篇了吧
从2016年使用以来.写法一变再变,不得不说.国内真的没什么技术交流环境.
同样的文章,同样的内容,复制再复制.盗来盗去.
有心得的文章太少了

说说MVP最开始的样子

public class Contract {
    public interface View{
    }

    public interface Presenter{
    }

    public interface Model {
    }
}

然后
activity实现View.
PresenterImpl实现Presenter
ModelImpl实现Model

这么写好吗?

不好,非常不好.

哪里不好?

乍得的一看,接口隔离,接口分明.多厉害,多有设计感.
实际,垃圾的一比

增

随便一个,增加一个方法.首先改契约类,然后需要实现.
工作量*2

删,改

同增一样,不过多了把之前有引用的地方也删了这一步.

查

想看源码,先看到的永远是这个契约类,然后再看实现.

随便改动一个地方,要改3个类,你跟我说这设计好?

想想也是醉了.不写接口,直接写pubic方法不行吗?

---

无人质疑的问题

不知什么原因,从第一篇MVP文章出来后,几乎所有的人都跟随一个风格.
无人质疑这种写法的问题.彷佛权威一样,不这样写就是错了
甚至连生成MVP类的插件都做出来了.
就算有生成的工具又如何.还是麻烦的要死.

MVP的设计

image.png

其实就这么一个设计.
是谁规定的MVP一定要写接口的呢?
一定要写个契约类的呢?
这就想到了一个问题.我们好像照搬的多,思考的少.
平时在开发群里聊天也是,
大家最喜欢问的也是有没有demo能抄.而不是讨论这个问题.当然,不是说问demo有错.而且不应该仅仅是要demo.

写个最简单的例子.

class M {
    
}

class V {
    val p by lazy {
        val p = P()
        p.attach(this)
        return@lazy p
    }

    fun detached() {
        p.detached();
    }

}

class P {
    var view: V? = null
    val m: M by lazy {
        return@lazy M()
    }

    fun attach(v: V) {
        view = v
    }

    fun detached() {
        view = null
    }
}

MVP其实无非就是这样子.

P控制

V视图,与P绑定,通过P来与M进行通信

M数据来源,只被P持有,与M完全隔离开.完全不打交道

一个这么简单的思想设计,非要搞得那么麻烦.

那么问题来了.写接口对不对?

对 ! 把功能抽象,写接口没错

但是

不应该每个页面都去写.
我们平时写代码.
有业务代码和封装功能代码.

我们应该只有在写封装代码,模板代码的时候才应该去写接口.写接口隔离.
而不应该每次写页面写业务代码都去写接口设计.
因为业务代码,界面可以说是唯一的.不需要抽象.没有设计接口的必要.

就一个问题.你这份业务代码.copy到其他地方能用吗?

答案是: 不能.

这不是和自己过不去吗.

那岂不是完全没有写接口的必要了?我写的都是业务代码.

不是!

我们应该把业务代码当中,可以重复使用的功能代码抽离出来.
这种就应该写接口,写隔离.抽象.

契约类需要吗?

我认为是不需要的.这玩意完全鸡肋,多此一举.
要说有用,只是为了把接口放在一起,好找而已.
但其实通过命名规则就可以了.

---

MVP用的多,心得也多.写的也多.哈哈.

您的喜欢与回复是我最大的动力－＿－
交流群:493180098