MVP那些事兒(5) 中介者與MVP

時間 2019-11-17

原文原文鏈接

這本書的實際價值也許還值得商榷。畢竟它並無提出任何史無前例的算法或者編程技術。它也沒能給出任何嚴格的系統設計方法或者新的設計開發理論——它只是對現有設計成果的一種審視。你們固然能夠將其視爲一套不錯的教程，但它顯然沒法爲經驗豐富的面向對象設計人員帶來多少幫助。程序員

摘自GoF《設計模式：可複用面向對象軟件的基礎》的最後一章面試

快速回顧

MVP那些事兒(4)……在Android中使用MVC（下） MVC的各個組件經過一些規則已經組合完成，同時加入了監聽機制，組成一條高效的事件傳送帶，讓事件流轉其中，在將來，咱們能夠在這條帶子上關鍵環節加入多個處理事件的方法，並把它們暴露出來供使用者自定義它們的具體功能，讓其擴展最大化。學習

這張圖中的每個 虛線圓點，表示着對外暴露的可操做事件的方法，在設計框架的時候，擴展性是着重要去考慮的，在事件流轉中「插入」鉤子方法，甚至是 鉤子對象，能夠說是一種經常使用的手段。

MVP

咱們以前已經經過大量的篇幅詳細的介紹了MVC架構，同時也開始着手搭建一個框架，目的是就是爲了能夠平滑的過渡到MVP，若是你對MVC架構基本概念的理解有些模糊，或只知其一;不知其二，不妨回頭耐心的看看以前的章節，畢竟MVC有不少部分是和MVP有共通性的，好比View和Model的職責等等這些，都與MVP是息息相關的，而本章的內容是將注意力放在它們之間的不一樣點上，不會過多的闡述它們之間共通的部分。若是已經閱讀了的朋友，結合本章內容你會很輕鬆的理解並抓住MVP的本質。

中介者模式（Mediator）

爲了能更好的理解MVC與MVP的區別，就要把它們具象的去討論，而不是簡單的停留在抽象的層面。MVP的出現必定是解決了MVC某一方面的不足，必然算是一種提高，而這提高的過程，必然也是思想的提高，但凡涉及到設計思想，也就逃不出大衆的思惟，咱們在處理一些問題時，都會碰到一些阻礙，人們在處理這些問題時爲了能造福後代，少走彎路，就把這些經驗流傳下來，古有三十六計孫子兵法，今有GoF的二十三種設計模式，都是爲了解決一些場景性的問題而制定的最優策略。因此，在MVC提高到MVP的過程當中，會不會也有前人留下的設計思想值得咱們去借鑑一下呢？在我學習MVP的時候，我發現了中介者設計模式與MVP的核心思想有很大程度的吻合，也特別想從中介者模式的這個角度去談談MVC與MVP之間的本質區別，其主要目的仍是但願能經過一個具象的例子，延伸到抽象的架構上去，加深理解，因此理解了中介者模式也就更容易去理解MVP。

中介者模式的出現是爲了解決對象間複雜的引用關係。爲了快速get到中介者模式的核心價值，咱們引入一個場景。

場景

假設你是一個項目組的開發人員，你的角色是開發，你有不少同事，他們分別爲，設計，美工，後臺，需求，測試。

同事類（Colleague）

你能夠把你的同事當作一個個的類，從你作爲出發點，你的同事統一稱之爲同事類，你在別的同事眼中也是他們的同事類，大家是一類人，均可以叫作同事類，

場景描述

因爲是新的項目，項目經理沒有到位，同事間溝通全都是點對點，相對比較混亂，沒有人負責流程。在項目進行中，項目經理到崗，他決定，全部的溝通都要先彙報到項目經理，而後再讓項目經理轉發命令到相應的同事。好比產品經理提出一個新的想法，先要傳遞到項目經理處，再由項目經理決定，到底須要開發仍是設計來參與這個需求，在這裏，項目經理承擔着中介者的職責，他相對於同事類來講就是中介者類。中介者設計模式只涉及到兩個角色，同事與中介者。

中介者的職責

首先，中介者的目的就是讓同事類之間「永不相見」，也就是所謂的「隔離」。並負責收集傳遞同事間的事件，在此期間作一些流程控制。

注意：設計不當，會使得中介者變的臃腫，不易維護。

同事類的職責

中介者的同事類能夠是無數個，同事類也能夠有共通的行爲，好比上班，下班，吃中飯。同事類也能夠徹底沒有共通行爲，好比有一類同事，它們可能只負責編碼，還有一類同事，它們可能只負責訂飯，編碼的不會訂飯，訂飯的也不會編碼。

在瞭解中介者模式的使用場景後，咱們經過一幅圖來對比一下：

沒有使用中介者

使用中介者

第一張圖，全部的對象都包含其餘的對象，對象間關係複雜。

第二張圖，全部的對象只和中介者（項目經理）交互，由中介者負責處理邏輯和轉發事件

那麼中介者模式和MVP架構有什麼聯繫嗎？咱們把上面的兩張圖簡化一下，還記得咱們以前是怎麼介紹MVC的架構圖嗎？沒錯，把具象的變成抽象的。

抽象化

咱們首先把同事類的個數從5個變爲3個：

經過對同事類的減小，咱們生成了一張對比圖，左邊的圖是沒有使用中介者的場景，右邊的使用了中介者的場景。對於左邊的圖是否是有些似曾相識呢？若是你們看了我以前寫的文章或者對MVC有了解的話，是否是很像MVC的架構圖？再看看右邊的圖是否是有點像MVP呢？也許有人會有疑問，像是像，但一個是模式，用來解決實際問題，而另一個是架構，不能夠相提並論，固然我本身也在以前的文章裏闡述過這個問題，設計模式和架構不是一個概念，解釋一下，並無說中介者模式就是MVP架構，而是借鑑了中介者模式中的部分思想，起碼從個數來講，中介者同事類的個數是沒有上限的，而MVP的同事只有2個，M和V，這裏指的個數是同一類同事，並非全部實例化的同事。 當咱們把具象的業務場景向上抽離直到變成抽象，最終咱們發現，在中介者模式裏的同事類，就如同MVC中的三個層，它們互爲同事，不計耦合的成本點對點的通訊， 即Controller並無起到隔離同事的做用，它就是一個普通的同事，而在MVP中，M與V是被隔離開來的，全部的溝通都要經過P來進行，這和中介者模式的思想是很是的類似的，只不過中介者更偏向於實際的場景，更加的具象而已。

深度解讀

公司不可能只有一個程序員或者產品經理，更或者是項目經理（咱們這裏討論的角色都是泛化前的，也就是接口）。舉個例子，項目的過程當中不知什麼緣由又換了一個項目經理，無論怎麼換他的核心職責就是中介者，又或者換了一個程序員，他可能有他獨有的特性，但核心仍是一個會敲代碼的同事類，在現實中，這種人員調動必定會存在的，若是你們都是點對點的溝通，那麼耦合是在所不免，假設一個產品經理角色依賴了最少四個以上的其餘同事，當這個產品不在了，或者須要替換，那麼他們之間的行爲都會消失沒法利用。而有了中介者，同事間的溝通是不須要知道接受方是誰，這一切都由中介者去操心。而同事類也能夠不用知道具體的中介類是誰，他們之間是絕對透明的，也許次日你即時通信軟件裏收到的信息是來自另一個項目經理的指令，這也就是所謂的「封裝/隔離」，也是接口的本質。

錯綜複雜的對象間關係

在中介者模式的章節裏，咱們知道這個模式的核心價值觀是爲了解決對象間錯綜複雜的關係，但除此以外，它還有一個很是酷的拓展能力，這也是MVP最爲重要的一個能力——可複用與可擴展性。 複用性和可擴展性纔是用好MVP的關鍵

MVP的擴展性

咱們繼續經過以前的場景來闡述MVP的擴展性，項目中一開始只開發了IOS平臺的軟件，這個時候公司決定增長Andoird平臺，以前項目已經有了一個完整的團隊，如今只須要加入一個Andoird程序員和一個熟悉Android設計的UI，由於IOS和Android程序員都有一個共同的能力，就是對接口理解，以及對設計和需求的理解是一致的，只不過他們使用的平臺不同，因此在泛化程序員的時候，咱們只要把平臺這一項放開便可，UI也是同樣，他們使用的工具和設計稿相同，只不過切圖的尺寸不一樣，而產品經理、項目經理、測試工程師、後臺工程師均可以直接拿來複用，而不須要另外組建一個團隊，這對公司來講是一件很是節省成本的事情，而同時，程序員組和UI組的到了能力擴展。再繼續舉個例子，在項目的開展過程當中，因爲追趕進度，須要加班，而項目經理週六日沒法加班，因而公司派了一個加班項目經理。他只有在週六日上班，因爲是加班，因此加班項目經理決定下班時間從七點調整爲五點，這樣當項目處於加班期時，員工五點下班，咱們的項目經理都有決定下班時間的功能，而這個功能是開放的。很不巧的是，咱們的產品經理也須要一個加班產品經理，這個加班產品經理他根本不知道加班項目經理和項目經理之間的區別，他一直覺得下班時間爲五點，而事實上他無需關心，一樣的，加班項目經理也不知道這個產品經理是個加班產品經理，他也無需關心這一點，他們之間永遠都是透明的。（仔細看這張圖，慢慢體會）。

總結

咱們看似是在講中介者，其實只是經過中介者來論述MVP架構的優點，中介者模式的出現是爲了解決對象間錯中複雜的關係，在沒有中介者的狀況下，全部對象都要認識彼此，有了中介者，它包含了整個系統的控制邏輯，中介者除了能解耦並增長對象複用外，還有如下幾點好處

控制邏輯集中，職責明確讓模塊更加方便維護

那麼MVP的出現就是爲了解決MVC各個層間的一個強耦合以及擴展不靈活等問題。因此在MVP中，P能夠是設計成爲一個接口，M和V也能夠設計成一個接口，這才能發揮MVP價值最大化。

我在剛接觸設計時，因爲理解不夠，一上來無論三七二十一先接口化，甚至有專門的插件幫你生成接口文件，但不少時候事與願違，整個項目到最後，接口的實現類也只用一個，甚至萬年不變.

在這裏多說一句，在使用MVP時，並非都要接口化的，必定要按照實際狀況去設計，若是真的只有存在一個實例，看似使用了MVP架構來作設計，但只是形似而已。這個時候要思考一下，項目是否到了須要考慮複用性和擴展性到的步了呢？仍是，到不如把它們寫成一團，反而少了一些沒必要要的類更易於閱讀和維護。

說點題外話

最近加入新公司，年末部門招人，我又責無旁貸的成了面試官，來面試的經驗從兩年到五年的七年以上的均有，三年以上的我基本都會問關於MVP和MVC的問題，但是能說明白的不多，即使說出來也還停留在使用層面，這其中還有的是teamleader，或項目負責人，若是這些級別的都不去考慮架構或只知其一;不知其二，難道還要期望本身下面的小弟嗎？這其實也是我對本身的擔心，我認爲程序員作到必定的階段，應該多去收集已知零散的知識點，對它們穿針引線，讓它們相互產生關聯，始終圍繞在一套思想體系當中，讓本身成爲這套體系的受益人，並不斷的改進和趨近完善，而在不斷完善的過程當中必然會吸取更多的知識（比起低素質，劈腿率高這些我無需證實，勤奮仍是須要證實一下的）。