前言
近期經(jīng)常在群里看到大神們在討論MVC MVP之類的東西捧杉，之前對MVC倒有一些了解倘核，也還有一些印象泣侮。因此也激起了對MVP探討的興趣。這幾天都在簡書上翻閱相關(guān)文章紧唱，也動手寫了些demo活尊。目前也還是云里霧里的，也許真要在項目中運用起來了漏益，才能真正領(lǐng)會吧蛹锰。
初衷
看了很多文章對于為何需要MVP模式都有相應(yīng)的介紹，大體的思想都是為了更好體現(xiàn)“低耦合绰疤、高內(nèi)聚”的設(shè)計思想，也就是為了提高代碼的可讀性和可維護性。關(guān)于這點有额，我有比較大的感觸晰骑，前段時間，接手一個同事的代碼余爆，發(fā)現(xiàn)其中一個activity的代碼將近2000行纷宇，方法體也是多得數(shù)不過來，其中涵蓋的功能自然臃腫蛾方，估計讓他來解釋像捶，也解釋不清了。其實想想桩砰，我們很多時候也是這樣拓春，項目一啟動，完工工期就擺在那里亚隅，不得不去正式硼莽，很多功能都是想著先實現(xiàn)，后期再優(yōu)化枢步。但項目能準時上線已經(jīng)是慶幸了沉删，哪還有優(yōu)化渐尿、重構(gòu)的時間。因此就會導(dǎo)致上述一個類中矾瑰，代碼臃腫砖茸，功能錯綜復(fù)雜，調(diào)理不清晰殴穴、維護極其困難等不良情況的出現(xiàn)凉夯。
VIEW
基于上述初衷中所描述的問題，大家都會很自然地想到采幌，view（在android中體現(xiàn)為activity）就應(yīng)該只履行其展示視圖的功能劲够，簡單明了。MVP模式就是這么做的：
View：繪制UI元素休傍，展示視圖征绎。
這也是我們?nèi)粘Ｊ褂玫腶pp中展示其形態(tài)的最直接方式，如顯示一張圖片磨取，一段文字人柿，一個按鈕等。就如同透過一個人的外觀來獲取自身對他的印象忙厌。
MODEL
研發(fā)應(yīng)用凫岖，必然離不開數(shù)據(jù)這個概念，不管是靜態(tài)的圖片逢净，還是從后臺獲取的某個動態(tài)數(shù)值哥放，都是數(shù)據(jù)的存在形式。在MVP模式中爹土，將對數(shù)據(jù)的操作獨立成為一個模塊甥雕，即Model：
Model:負責數(shù)據(jù)（本地數(shù)據(jù)、平臺數(shù)據(jù)）操作（增着饥、刪犀农、改、查）
PRESENTER
從上面兩個角度來看宰掉，數(shù)據(jù)是數(shù)據(jù)呵哨，界面是界面。但我們實際使用中轨奄，數(shù)據(jù)要依賴于界面才得以展示孟害，用戶在界面上所做的操作，也會涉及到數(shù)據(jù)的變化挪拟。M和V之間有著必然的聯(lián)系挨务，在MVP模式中，將該部分操作寫在了P里面：
Presenter:處理用戶交互
