Android MVP系列（四）之完整MVC

今天这篇文章主要分为两大部分：

一、为上一章的MVC赋予灵动的生命；
二、指出MVC的不足和引出MVP的优点；

题外话

可能有人会说，你写个MVP，为啥用了前面三篇（Android MVP系列（一）、Android MVP系列（二）之MVC结构、Android MVP系列（三）之MVC中篇）加上本篇来叙述MVC，我花这么几个章节来详细解释MVC，就是为了让我们能更加容易理解、掌握MVP的框架，通过MVC来平滑过渡到MVP，让读者能更加的自然的接受，不至于突兀，有点不知所措。如果还没有阅读过之前章节的同学，不妨花点时间耐心看看之前的章节，MVC和MVP是有很多共性的。

第一部分：为MVC赋予灵动的生命

沟通机制

上一章我们最后搭建了一个MVC框架的雏形，但是在文末的时候我提出说：这个框架看起来比较死板、灵活性不强，感觉哪里怪怪的，缺少点生命灵性。
这就是我这个章节要重点讲解的：沟通机制。看上一章我们搭建的框架，没有哪个地方有沟通机制，所以看起来比较死板。
JAVA里面有一种设计模式叫观察者模式，那么这里就是我要说的沟通机制；如果不清楚的也没关系，我会一步一步的讲解。

观察者模式也叫：发布-订阅模式。

观察者模式的主要两个人物：
Observer(观察者)、Obserable（被观察者）

整个事件的驱动过程：
订阅（Subcribe）、发送事件、接收事件、处理事件

那我们已经清楚观察者模式的基本结构，那么我们将观察者模式应用到我们的MVC框架中，让框架赋予灵性。

场景

在之前的MVC框架上，我们增加需求：

给列表增加刷新功能

MVC框架添加监听机制满足功能需求

第一步、创建观察者

       首先我们想想需求，我们是要刷新列表，我们需要观察者观察什么呢？这个需求当中最主要的就是刷新数据，也就是说最重要的就是数据是否刷新完成是一个点，这个点就是我们要观察的目标。所以我们的观察者就需要具备数据是否刷新完成的能力

按照上面的推理步骤我们可以写出一个观察者接口：

/**我是一个“观察者”**/
public interface Observer {
   
 /**监听数据刷新完成**/  
 void  onRefreshFinish(List<NewsBean> data);
}

这就是我们的观察者了，但是我们还没写到MVC框架里面让谁有这个观察者能力呢？这里我们就需要明白MVC框架的分层理解了，回顾一下：

Module层职责

Module层数据模型层，对业务逻辑的处理，数据库、网络、算法等。

View层职责

1.呈现M层的数据
2.主动询问或者被动监听（例如：下拉刷新列表主动询问）
3.通知C层处理
4.接收C层，改变UI

Controller层职责

接收V层的操控，并转调给M层来改变V层UI或者状态

按照功能来区分的话，我们看得出只有Controller层最合适，由于它主要是接收View的控制，转调Module去服务器刷新数据，再来改变View刷新列表。

因此我们赋予Controller观察者的能力：