前言
最近專案開始用mvp模式進行開發，為什麼不用mvc？你懂得。經過幾個版本迭代，邏輯已經被巢狀的面目全非，無法下手。下面簡單介紹，畢竟網上已有好多分享！
隨著ui建立技術的功能日益增強，ui層也履行著越來越多的職責。為了更好地細分
檢視(view)與模型(model)的功能，讓view專注於處理資料的視覺化以及與使用者的互動，同時讓model只關心資料的處理，基於mvc概念的mvp(model-view-presenter)模式應運而生。
話說你懂mvc嗎？什麼是mvc？
在mvp模式裡通常包含4個要素：
(1)view:負責繪製ui元素、與使用者進行互動(在android中體現為activity,fragment);
(2)view inte***ce:需要view實現的介面，view通過view inte***ce與presenter進行互動，降低耦合，方便進行單元測試,（向面向介面開發靠攏）;
(3)model:負責儲存、檢索、操縱資料(同時也實現乙個model inte***ce用來降低耦合);
(4)presenter:作為view與model互動的中間紐帶，處理與使用者互動的負責邏輯。
下面類圖是mvp的兩種方式。一種初級版本，另一種是官方推薦的一種版本。完全遵從mvp模式，肯定會捨棄一些方便性（發起網路，在model層進行，之前到處都可以發網路activity 中，fragment中），換來的是高質量，高可測，可維護以及**健壯，美觀，可讀性……
類圖1.初級版本 mvp三層對應各自上層介面
model— model inte***ce,presenter—-presenter inte***ce view—-view inte***ce. 各層之間通訊使用上層介面，這也是提倡的面向介面程式設計。
缺點：乙個activity 對應 6個類（ 3個介面，3個實現類）
優點：可復用性高（介面職責要單一）
上面uml推薦第一版可以這樣搞，團隊熟悉了mvp寫法，就可以用下面官方提供的寫法。當然直接走下面也不攔著你。
貼**更直觀，taskdetailcontract
/**
* this specifies the contract between the view and the presenter.
*/public
inte***ce
taskdetailcontract
inte***ce
presenter
extends
basepresenter
}
使用起來就很方便了
p實現方式
class
taskdetailpresenter
implements
taskdetailcontract.presenter
v實現方式
class
taskdetailfragment
extends
fragment
implements
taskdetailcontract.view
缺點：
理解起來有點繞，這也算不上缺點
優點：使用乙個鏈結器概念，將view 和 presenter 整合到聯結器中。功能內聚性高。
符合官方規範，可擴充套件性高。
下面方式屬於半成品，只有view,presenter沒有model層，網路請求放到presenter中，缺點就是網路放入p層進行請求處理，同乙個專案中多個地方呼叫同乙個請求鏈結需要呼叫多次，如果有model層，就可以拿來復用。只需拿到model inte***ce就可以呼叫。
當然團隊內部也討論過，是否需要完全遵從google mvp 規範。這個看團隊取捨了。個人建議，專業人士做專業事情，盡量遵從google mvp規範走。
初粗嘗前端工程
最近幾天沉迷搭建部落格，學習了各種nodejs工具，總的來說是這些 express react styled components forever react webpack這些工具之前也有嘗試著學習過，但是始終沉不下心來好好學，最近比較有時間，也打算參與學校一些專案了，又有個小夥伴和我介紹了怎麼通...
初嚐electron vue專案搭建
以前只見過，但是一直沒時間來玩玩，最近公司有需求重構某個應用做桌面程式，便開始了探索之路 文件 我的環境 node 14.7 yarn 1.22.4 windows10專業版 安裝 vue cli 和 腳手架樣板 npm install g vue cli vue init simulatedgre...
初嚐結對程式設計的甜頭
聯調的方式，形式上有點象結對程式設計，我是那個坐著旁邊 只說不作 的人，真正寫 的仍然是客戶端的人員，我主要負責幫客戶端人員理清他們的邏輯和思路，對現有的架構和 提出修改建議，同時 監督 客戶端人員的編碼過程，幫助其及時糾正由於思維 盲角 導致的小錯誤。這一兩個星期下來，感覺頗好，同事之間的合作既輕...