一個有別於Android MVP pattern的設計模式發想 — VPSM模式

工程師們畢生都花大部分的時間在思考怎麼可以讓程式架構更好維護，有更多的擴充性,更優異的模組化設計。所以在工作之餘我也常常在思考是不是有更好的設計模式，或是把現有的設計模式分析他的優缺點再加以進化變成比較不一樣的設計模式，目的是讓程式的架構進化，更符合在目前客戶多變的需求下可以更快的做程式的更動以及擴充。

1. MVP pattern

在介紹VPSM設計模式之前，我們先來複習一下MVP pattern。

相信有許多Android的開發者已經有對最近蠻流行的MVP pattern有所了解，甚至已經有許多市面上新產品已經有使用MVP pattern來做App的開發架構。

MVP pattern 主要的組成元素有三個,分別為Model，View，Presenter。
Model , View ,Presenter各自所負責的範圍分別如下:

Model — 提供資料、儲存資料、取得資料 例：SharedPreferences、呼叫API
View — 負責UI呈現，例如： Activity、Fragment
Presenter — 負責邏輯處理

各位心中會有個疑問，既然已經有MVC的架構了為什麼要用MVP呢?一定有什麼過人之處，MVP pattern擁有以下優點：

A.分離了View的邏輯與資料邏輯,並且降低了耦合
B.讓Activity與Fragment的程式碼更為簡潔
C.執行單元測試時更友善了
D.降低Memory Leak以及OOM的發生機率

但是！MVP並非沒有缺點，在有複雜的功能頁面，還是會造成Presenter或者是Model變得肥大的窘境。

2.VPSM pattern

或許會有人這麼問，”已經有了強大的MVP，你自己沒事又發想一個設計模式做什麼呢?跟著潮流走就好了呀”

當然是好的設計，一定會再出現更好的設計，但是，這些更好的設計都是來自於發想。

VPSM設計模式是我利用了MVP的架構再去做一些調整與發想。想解決的問題在於Model與Presenter的肥大問題，VPSM多了個”S”到底是什麼呢？讓我繼續說下去。

多了個S，這個S要被穿插在Presenter與Model之間，我將它稱為”Service”
。在說明為什麼要加入Service這個角色之前，先來看看在VPSM模式中View，Presenter，Service，Model(DataModel)各自負責什麼工作

View — 負責UI呈現，例如： Activity、Fragment
Presenter — 負責邏輯處理
Service — 負責整合多個Model所提供的資料以服務窗口的概念，提Presenter完整的整合服務窗口 例如 ：UserService 可以提供取得個人資料，個人設定的最愛資料列表，個人社交清單等等
Model — 提供資料、儲存資料、取得資料 例：SharedPreferences、呼叫API

由上面的設計來看，很明顯的Service扮演了一個提供整合服務的角色，Service除了提供Presenter所需要的資料，他更重要的任務在於整合目前檯面上有的DataModel所提供的資料並加以做整合，大約的結構如下圖所示：

看完圖片，不免俗的需要舉個例子才是王道。
假設有個IM(即時通訊)的好友列表如下圖:

這個畫面需要的資訊有好友的頭像，好友的暱稱，好友的自我介紹，好友上線狀態。這時候會有兩個API來構成這個畫面。第一個API是好友列表資訊，第二個API則是好友的上線狀態。其中好友列表資訊的資料來自於FriendListDataModel，好友的上線狀態資訊則來自於UserConnectionStatusDataModel。

在這時候會有一個稱之為UserService提供GetFriendList method來整合這兩個DataModel得到的資訊來整理成畫面所需要的資料給Presenter

這樣的設計會帶來什麼好處呢？

1. 減少Presenter的肥大情形，讓Presenter更輕量，Service可以分擔一點Presenter處理邏輯上的負擔
2. Service可以在商業邏輯變更的時候快速的修改所提供服務的資料整合部分，Service有高度的自由度可以做內容的修正
3. 減少維護時的負擔

這次的發想希望未來可以在工作上運用到，屆時再來跟大家分享一下實作的心得啦