今天這篇文章主要分為兩大部分：

一、為上一章的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觀察者的能力：

/**我是一個Contorller，同時我就是觀察者**/
public class Controller implements Observer{
 /**接收事件**/
 @Override
 void  onRefreshFinish(List<NewsBean> data){
  //處理事件
 }
  ...
  ...
  ...
}

第二步、建立被觀察者、並訂閱

這裡毫無疑問就是Module層是被觀察者，Module去訂閱

/**這是一個Model**/
public class Module{
private IView view;
private Observer observer;

//構造方法傳入View
public void Module(IView view){
this.view=view;
}
//訂閱觀察者
public void addObserver(Observer observer){
this.observer=observer;
}
//從伺服器請求獲取新聞列表資料
void getNewsData(boolean flag) {
//耗時獲取資料
...
//將伺服器返回的List<NewsBean>集合dataList儲存到本地
this.saveCacheNews(dataList,flag);
}
//儲存新聞列表到記憶體中
void saveCacheNews(Lis<NewsBean> dataList,boolean flag){
//儲存到本地
...
//判斷下重新整理還是初始化
if(flag){
 //傳送事件
 observer.onRefreshFinish(dataList);
 }else{
  //通知view 重新整理列表了
  view.updateView();
 }

}
//從記憶體快取獲取資料
NewsBean getNewsCache() {
//記憶體中去獲取資料 datas
...
return datas;
}
}

第三步、訂閱者接收事件

/**這是一個Contorller**/
public class Controller implements Observer{
private IView view;
private Module module;
//構造方法注入View
public void Controller(IView view){
this.view=view;
}
//注入Module
public void Controller(Module module){
this.module=module;
}
//轉調Module載入資料
void loadNewsList(boolean flag) {
//做個判斷是重新整理還是初始化
 if(flag){
   module.getNewsData(false）;
   view.showLoading();
 }else{
   if（module.getNewsCache() == null）{
     //執行Modle
     module.getNewsData(false);
     //執行View開始載入資料了，顯示載入動畫
     view.showLoading();
    }
  }
}
 /**接收事件**/
 @Override
 public void onRefreshFinish(List<NewsBean> datas){
  //處理事件 onDataBack哪兒來的，我們處理view的時候說明
  view.onDataBack(datas);
 }
}

最後一步，我們View中怎麼處理事件的呢？
我們現在的框架算是比較完整了，

public class MainActivity extends AppCompatActivity implments IView{
@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//初始化Controller,this就是View，通過構造器注入
Controller controller = new Controller(this);

//初始化Model，Model -> View and View -> Model
Module model = new Module(this);
//module注入到Controller
controller.setModule(module);
//Controller -> Model  這個地方就是我們的訂閱事件了  controller是Observer的實現類
model.addObserver(controller);
//初始化，讓Controller轉調Module請求資料
this.viewInit(false);
}
@Override
public void updateView(){
//主動請求Model獲取資料
NewsBean data = module.getNewsCache();
//更新ui
list.update(data);
//隱藏loading介面
this.hideLoading()
}
@Override
public void showLoading(){
list.showLoading()
}
@Override
public void hideLoading(){
list.hideLoading
}
//重新整理介面資料了，通知Controller
//flag 表示判斷是初始化介面還是重新整理資料 false 初始化 true 重新整理
public void viewInit(boolean flag){
controller.loadNewsList(flag);
}
//相當於我們的下拉重新整理列表的時候，activity中呼叫onRefresh方法
pulic void onRefresh(){
 controller.loadNewsList(true);
}
 //Controller層接收事件之後，控制View處理事件，重新整理介面
 public void onDataBack(List<NewsBean> datas){
 list.update(datas);
 this.hideLoading
 }

}

這樣我們的MVC的框架就算是比較完整了；

View層：觸發重新整理、接收資料、更新UI介面，資料怎麼來的一概不管。
Contronller層：接收View控制、轉調Module層請求資料、控制View的狀態、監聽重新整理資料完成。
Module層：處理資料、請求資料。

各個層的職責非常清楚、便於維護、邏輯清晰等優點。

總結

       在MVC這個模式中，我們建立的溝通機制，是最常見的方式。但是我們很多人一眼看的出來，在View層中既有Module物件，又有Controller物件，Controller層中也有Module物件，Module層中又含有Controller物件，這樣複雜的物件引用關係，估計很多人都暈了。
       而且這種複雜的引用關係，不利於管理，可擴充套件性也差，所以這才有了我們MVP的框架，MVP有兩個非常重要的能力：複用性和可擴充套件性，還有就是解決物件的複雜引用關係、便於維護。

第二部分引出MVP

新的場景

我們都是上班族，畢竟面臨租房子的問題，那麼我們經常租房子肯定是找中介。現在我們就有三個人物：租客、中介、房東三個人物

這個圖和我們的MVC的圖片貌似神似啊（原諒我畫的有點醜），但是這個場景就和我們的MVC非常符合，但是現在新的需求改變了：

由於房東比較忙，他給中介說，我比較忙我不想和租客去溝通價格、修理傢俱。。。等等很多的事情，你都給我辦了，包括租金，租約你都處理了，我就收錢就好了，其他的我不管。現在的圖形就演變成下面這樣了：

當然這個圖裡面付錢，籤合同等都是中介完成，就沒有畫出來了，但是我們可以清楚的看到房東和租客沒有任何聯絡了，一切事情找中介就好了。那麼這張圖和我們的MVP的經典圖片又有什麼區別呢？

這種模式下人員關係方面簡單得多，這裡我們把：

租客==View、中介==Presenter、房東==Module

       現在的關係非常清楚，租客（View）只和中介（Presenter）聯絡，房東（Module）也只和中介聯絡（Presenter）；假如中介換人了，按照之前的結構不需要任何改變，複用性強；現在房東只管收錢就好了，其他的事情都由中介處理，租客交租金、修電器、出現的等等問題，直接和中介溝通解決，等於可擴充套件性也強，最終知會一下房東就好。不知道這樣解釋清不清楚，假設如果還是理解不清楚，沒關係，下一章節我們用程式碼的形式展示就會很清楚了

那就期待一下章節的從MVC平滑過渡到MVP，讓你輕鬆掌握MVP。

原創不易，如果覺得寫得好，掃碼關注一下點個贊，是我最大的動力。

關注我，一定會有意想不到的東西等著你：
每天專注分享Android、JAVA乾貨

備註：程式圈LT
微信掃一掃
關注該公眾號