背景：地圖對于很多應用來說已經不是一個稀罕的東西了，很多軟件里都有這個功能，特別是那些房產類、外賣類的應用，地圖可以算是其中一個很重要的模塊。通常情況下，地圖是在這些應用的早期開發的，趕著時間開發，因此難免會存在設計粗糙、耦合嚴重的情況。隨著產品線的不斷發展，地圖模塊也變得越來越臃腫，來一個功能就往里面扔，久而久之，哪怕只是對它做一點小的改動，都會比較費勁。這也是為什么很多開發者不愿意產品老是調整地圖的原因，因為實在是改不動了。

然而逃避終究不是解決問題的辦法，放著不管，只會越來越嚴重，有病還是要趁早治。

今天我們就來看一下，怎么給一個臃腫的、已經病入膏肓的地圖模塊做手術。

醫生看病時要先了解病人的情況，然后對癥下藥，那些胡亂開藥的醫生一定都不是好廚子。因此首先應該花點時間好好的了解這個“病人”的情況。在看了一天的自家項目中地圖模塊的“病”后，我總結了一下我們項目中地圖模塊的問題，這個問題，應該也是大部分地圖模塊的問題，在每一個問題的后面給開出對應的“藥方”：

• 聲明了大量的用來記錄搜索條件的全局變量。在地圖中通常會有搜索的功能，需要記錄用戶的各種搜索條件，像我們這種房產類的軟件，查詢條件要有十五六個，然后就很黃很暴力的聲明了十五六個全局變量來進行記錄，再加上存放查詢結果的數組、字典和其他的中間變量，那簡直叫一個酸爽啊。其實我們完全可以聲明一個模型來管理這些搜索條件、存儲搜索結果以及其他的中間變量，這樣做的好處很多，不僅可以很方便的設置默認值。并且在其他類中要使用數據的話，只需要耦合一個模型就好了，方便管理，另外還可以通過優秀的框架（自行百度）將模型直接轉換為對應的字典，傳給服務器，你只需要過濾掉那些不該上傳到服務器的字段就可以了。

• 網絡層沒有分離出來，很多人糾結于網絡層屬于MVC中的哪一層，因為貌似那里面沒有考慮到它們的位置，因此就將大量的網絡請求寫到了視圖控制器里，然而先不論MVC中對網絡層的定位如何，網絡層負責的功能就是根據請求參數獲取數據，然后對數據做跟業務強相關的轉換與處理，除此之外貌似也沒有別的了，它的職能是明確的、單一的，也是固定的，完全可以聲明一個專門處理該業務相關的網絡請求的對象，傳給它請求參數，它處理后返回給你想要的結果，就這么簡單。視圖控制器不需要去關心它里面怎么對數據進行處理與轉換。

• 視圖控制器直接操作mapView，在VC中直接操作mapView貌似是一件很正常的事情，然而仔細去看的話，會發現我們對mapView的很多操作是跟業務無關的操作，比如mapView的創建、定位到當前所在位置、設置地圖層級等功能是跟業務沒有什么關聯的弱業務，而像添加標注Annotation模型，因為會涉及到添加自定義的Annotation的問題，這個是跟業務強相關的，變化的可能性是比較大的，如果要加一種新的標注類型，那么我們就要到視圖控制器里，在上千行代碼中找到這塊功能進行修改，不便于模塊測試，所以還是有必要聲明一個mapView的manager來管理這些事情，其中弱業務可以直接寫在manager里，而那些跟業務強相關的（主要就是標注Annotation模型的創建與添加）可以寫在manager的分類中處理。以后要加新的標注模型的話，直接到分類中進行修改就可以了。

• mapView的代理沒有從視圖控制器中剝離出來，mapView的代理方法有好多，如果將這些代理方法全都寫到視圖控制器中的話，那么勢必會造成VC中的代碼過多的情況，特別是根據Annotation返回對應的標注視圖的代理方法，這個方法跟具體的業務強相關，如果你的地圖中需要根據地圖等級、用戶身份等條件顯示不同的標注視圖，那么最好還是單獨聲明一個MapViewDelegate類來做這個事情吧，好處就是減輕了VC的壓力，并且所有跟標注視圖相關的邏輯處理都單獨剝離出來，也方便你以后的維護。

再將代理從視圖控制器中分離出來后，很自然的就會遇到一個問題，那就是標注View的點擊事件誰來處理，換句話說就是它的target是誰。

如果沒有剝離出MapViewDelegate，那么我們的做法通常是將視圖控制器VC作為這些標注的target，所有的點擊事件都是視圖控制器進行處理，現在既然剝離了，總不能在MapViewDelegate中再去耦合具體的視圖控制器吧，這樣的話它的復用性就會降低，怎么解決這個問題呢？

聲明MapViewTargetProtocol協議

在這里我們聲明了一個協議來解決這個target問題，將所有標注View的點擊方法都寫在了這個協議里，并且這些方法是必須實現的方法。這樣一來凡是遵循這個協議的對象都可以作為標注視圖的target，這樣MapViewDelegate中就不需要再耦合某個具體的target了，實現了一定程度的解耦，在使用中，由于我們的點擊事件不多，所以我們讓視圖控制器遵守了這個協議，但是如果標注的點擊事件過多，那么我們就可以專門聲明一個類當做這個target,解放視圖控制器。

以上就是針對地圖模塊的解耦方案，以下是上面提到的幾個類：

• MapSearchKeyModel,用來管理所有數據的模型，需要被下面的類耦合。
• MapViewManager，用來管理mapView，并處理mapView的弱業務邏輯。
• MapViewManager+Annotations,分類，專門用來處理annotations標注模型。標注模型的添加與移除都在這里進行。
• MapNetWorkManager,負責網絡請求，處理返回數據。
• MapViewDelegate,專門用來實現mapView的具體代理方法，所有標注視圖的處理都在這里。
• MapViewTargetProtocol,用來解決標注視圖View的target問題。
• MapViewController,視圖控制器。

這樣一來，我們的視圖控制器中的代碼就從天殺的1700行銳減到了350行，并且各模塊的職責清晰，應該夠它再活蹦亂跳一段時間了。
因為它不是很丑了。。。（哈哈，長得好看果然在哪里都有用）

此處應有demo。