iOS 開發 – 均衡程式碼職責

林欣達發表於2016-10-22

前言

文章的標題有點繞口,不過想了半天,想不到更好的標題了。本文的誕生有一部分功勞要歸於iOS應用現狀分析,標題也是來源於原文中的“能把程式碼職責均衡的劃分到不同的功能類裡”。如果你看過我的文章,就會發現我是一個MVC主導開發的人。這是因為開發的專案總是算不上大專案,在合理的程式碼職責分工後專案能保持良好的狀態,就沒有使用到其他架構開發過專案(如果你的狀態跟筆者差不多,就算不適用其他架構模式,你也應該自己學習)

 11783864-acab38493e59bbdb

OK,簡短來說,在很早之前我就有寫這麼一篇文章的想法,大致是在當初面試很多iOS開發者的時候這樣的對話萌生的念頭,下面的對話是經過筆者總結的,切勿對號入座:

Q: 你在專案中使用了MVVM的架構結構,能說說為什麼採用的是這種結構嗎?

A: 這是因為我們的專案在開發中控制器的程式碼越來越多,超過了一千行,然後覺得這樣控制器的職責太多,就採用一個個ViewModel把這些職責分離出來

Q: 能說說你們控制器的職責嗎?或者有原始碼可以參考一下嗎?

面試者拿出電腦展示原始碼

最後的結果就是,筆者不認為面試者需要使用到MVVM來改進他們的架構,這裡當然是見仁見智了。由於對方程式碼職責的不合理分工導致了ViewModel層幾乎沒有業務邏輯,從而導致了控制器的失衡,變得笨重。在這種情況下即便他使用了ViewModel將控制器的程式碼分離了出來,充其量只是將垃圾挪到另一個地方罷了。我在MVC架構雜談中提到過自身對MVC三個模組的職責認識,當你想將MVC改進成MVX的其他結構時,應當先思考自己的程式碼職責是不是已經均衡了。

碼農小明的專案

在開始之前,還是強烈推薦推薦《重構-改善既有程式碼的設計》這本書,一本好書或者好文章應該讓你每次觀賞時都能產生不同的感覺。

正常來說,造成你程式碼笨重的最大凶手是重複的程式碼,例如曾經筆者看過這樣一張介面圖以及邏輯程式碼:

 12783864-c74ad67c7948d848

別急著嘲笑這樣的程式碼,曾經的我們也寫過類似的程式碼。這就是最直接粗淺的重複程式碼,所有的重複程式碼都和上面存在一樣的毛病:亢長、無意義、佔用了大量的空間。實際上,這些重複的程式碼總是分散在多個類當中,積少成多讓我們的程式碼變得笨重。因此,在討論你的專案是否需要改進架構之前,先弄清楚你是否需要消除這些垃圾。

舉個例子,小明開發的一款面向B端的應用中允許商戶新增優惠活動,包括開始日期和結束日期:

由於商戶同一時間只會存在一個優惠活動,小明把活動寫成了單例,然後其他模組通過獲取活動單例來計算折後價格:

小明在開發完成後優化程式碼時發現了多個模組存在這樣的重複程式碼,於是他寫了一個NSDate的擴充套件來簡化了這段程式碼,順便還新增了一個安全監測:

過了一段時間,產品找到小明說:小明啊,商戶反映說只有一個優惠活動是不夠的,他們需要存在多個不同的活動。小明一想,那麼就取消Promotion的單例屬性,增加一個管理單例:

隨著日子一天天過去,產品提出的需求也越來越多。有一天,產品說應該讓商戶可以自由開關優惠活動,於是Promotion多了一個isActived是否啟用的屬性。其他模組的判斷除了判斷時間還多了判斷是否啟動了活動。再後來,還新增了一個synchronize屬性判斷是否可以與其他活動同時計算判斷。最近產品告訴小明活動現在不僅侷限於折扣,還新增了固定優惠,以及滿額優惠,於是程式碼變成了下面這樣:

這時候模組獲取優惠活動資訊的代價已經變得十分的昂貴,一堆亢長的程式碼,重複度高。這時候小明的同事對他說,我們改進一下架構吧,通過ViewModel把這部分的程式碼從控制器分離出去。其實這時候ViewModel的做法跟上面小明直接擴充套件NSDate的目的是一樣的,在這個時候ViewModel幾乎無作為,基本所有邏輯都在控制器中不斷地撐胖它。小明認真思考,完完全全將程式碼閱覽後,告訴同事現在最大的原因在於程式碼職責混亂,並不能很好的分離到VC的模組中,解決的方式應該是從邏輯分工下手。

首先,小明發現Promotion本身除了儲存活動資訊,沒有進行任何的邏輯操作。而控制器中判斷活動是否有效以及折扣金額計算的業務理可以由Promotion來完成:

除此之外,小明發現先前封裝的活動管理類PromotionManager本身涉及了網路請求和資料管理兩個業務,因此需要將其中一個業務分離出來。於是網路請求封裝成PromotionRequest,另一方面原有的資料管理只有獲取資料的功能,因此增加增刪改以及對活動進行初步篩選的功能:

最後,小明發現其他模組在尋找最優惠活動的邏輯程式碼非常的多,另外由於存在滿額優惠和普通優惠兩種活動,進一步加大了程式碼量。因此小明新建了一個計算類PromotionCalculator用來完成查詢最優活動和計算最優價格的介面:

當這些程式碼邏輯被小明分散到各處之後,小明驚訝的發現其他模組在進行計算時剩下幾行程式碼而已:

這時候程式碼職責的結構圖,小明成功的均衡了不同元件之間的程式碼職責,避免了改變專案原架構帶來的風險以及不必要的工作:

 13783864-dfb614fc2ec87d9e

尾語

這是第二篇講MVC的文章,仍然要告訴大家的是MVC確確實實存在著缺陷,這個缺陷會在專案變得很大的時候暴露出來(筆者沒有開發過大型專案的弱雞),如果你的專案結構分層做的足夠完善的話,那麼該改進更換架構的時候就不要猶豫。但千萬要記住,如果僅僅是因為重複了太多的無用程式碼,又或者是邏輯全部塞到控制器中,那麼更換架構無非是將垃圾再次分散罷了。

關注iOS開發獲得筆者更新動態
轉載請註明地址以及作者

相關文章