iOS Swift Architecture VIP Clean View Presenter ViewController Interactor

大話 Clean Swift - 觀念篇

Morris Mao 2022/09/29 17:36:43
318

Clean Swift 這個程式架構取自於知名技術作家 Uncle Bob 的其中一本著作 Clean Architecture,而他其中一本著作 Clean Code 也是紅遍軟體開發界。Clean Code 講述如何把程式寫好,而 Clean Architecture 則是講述如何把程式寫的容易測試和容易擴充及除錯。相信 Clean Swift 的原創人 Raymond Law 想必也是 Uncle Bob 的書粉吧!才以 Clean 來命名。

 

 

只要踏入程式開發一段時間,除了把程式基本語法弄熟,且能把需求功能完成後,就會開始遇到程式碼開始雜亂的問題,這時有些工程師會試圖去了解一些軟體工程相關技能知識,例如會去學習重構方法、學習設計模式、學習如何寫出好的程式架構。但其實前面講得這三種方式都是在講同一件事,只是用不同的面向來解釋。

重構 = 使用 Martin Fowler 所著作重構聖經裡提及的數十種方法進行程式改造。

設計模式 = 使用 Gang of Four 四人幫所歸納出來的二十三種設計模式進行程式所需情境應用。

程式架構 = 沒有特定發明人,都是有經驗的開發大神所以釋出的開發架構,其實每種架構差異性不是太大。

重構和設計模式並非是今天的主題,坊間有很多經典著作都可以參考。

 

 

Clean Swift 所屬的是程式開發架構,跟它類似的是VIPER,另外像 MVP、MVVM 也是開發界經常使用的程式開發架構。

很多開發者會憂心要選擇哪一種架構,但其實這沒有標準答案,就算是一般預設使用的 MVC 也並非不好。那什麼時候該選擇除了 MVC 以外的架構呢?簡單說就是專案大小而定,如果開發團隊定義這專案屬中大型專案,那則建議使用 MVC 之外架構性更好的程式架構。

今天要介紹的是 Clean Swift 觀念,所以不會看到任何程式碼。我認為觀念是初始學習一件事要先建立的,能理解其觀念能減少碰壁機會,日後也能舉一反三,以下是今天觀念篇的正文。

說到程式架構很多開發者其實多少會心理產生畏懼感,就如同設計模式,我相信很多開發者買了書,但還是只會使用其中幾種常用的設計模式,其他設計模式在去有效使用,光看程式碼範例也無法了解因由為何 (在此我推薦重構,由重構去推衍到一種設計模式)。尤其在程式技術書的教學有很多抽象的詞語,光要理解都是一門苦差事。

但其實程式架構早就已經出現在我們的周圍,為什麼我們會無法自然的去使用呢?原因在於這支程式是你自己在寫的。

當這支程式都是你自己在寫的時候,通常就會從頭到尾把程式一次寫完,然後讓功能能正常執行。所以要了解程式為何要拆解成各種架構要回到理解分工合作的概念。

生活充斥著很多分工合作的事,例如運動。

 

 

以上兩種運動都是很常見的運動,這兩種運動在正規比賽中都不是一個人就能完成比賽,而是要團隊分工合作。球隊中不管排隊還是籃球,每個角色位置的功用都是不一樣的,我想這點很好理解,如果每個角色都由一人來作,我想會相當累人,甚至無法進行下去。也就是這樣,所以在籃球場從邊線把球傳出來一般是後衛選擇,在籃下的是中鋒選手,唯獨把角色區分出來,讓每個角色專注在自己的任務上才能把功能發揮到最好。除了運動以外,我想還有非常多的例子都能看到架構分層的重要性,舉凡銀行、郵局、大賣場、學生班上股長等等不勝枚舉。

那 Clean Swift 也有這些團隊分工嗎?是的,只是現實上這裡的團隊指的是我們要完成的功能。但今天我們仍是擬人法的方式來理解這團隊分工是怎麼作的。接下來我們有請五位能幹的角色出場。

 

 

這五位分別擁有重大的使命,本來我們把一個功能交給一個人作,現在要分拆給這五位來做,我想這薪水成本會提高,但我相信是值得的。(是的,你沒看錯,使用分層的程式設架並不會讓程式執行效率提升,甚至是可能會減少執行效率的)

今天有一項任務要完成,這五人幫要怎麼進行作業呢?(以上直接以人名作比喻,請自行對應原始程式檔名,例如大衛是ViewController)

 

任務名稱:向NASA美國太空總署取得地球跟月球的距離後顯示在看板上。

Mission Start!

1. 一開始我們請艾瑪進行看板顯示地球跟月球距離畫面的排版,把顯示距離地方作好。

2. 大衛負責主控,他會跟翠絲發出請求,跟翠絲說何時要去跟NASA索取距離資訊。

3. 翠絲取得距離資訊後,把原始資料格式轉發給龍一

4. 龍一發現翠絲送過來的資料只有單位純數位,沒有距離單位,他的工作是作資料格式化處理到看板上可以直接使用。

5. 龍一處理完後把資料送往主控的大衛,因為龍一不能直接跟艾瑪接觸,必需由大衛艾瑪接洽。

6. 大衛確認手上拿到經格式化好的資料後,把最終資料交給艾瑪顯示距離。

值得一提的是,此次任務沒有讓洛特出馬,因為這次任務比較單純沒有畫面跳轉要帶資料的需求,所以洛特在辦公司待命。

經過一連串的分工合作,團隊終於把月球跟地球的目前距離展示在看板上,因為經研究月球跟地球距離逐年越來越近,所以必需作好這個觀察才行。

 

藉由以上這個簡單的需求務任,我想大家都能在很短的時間完成它,甚至可能會想,這不就單純Call API就完事了嗎?是的,這個例子很單純,但一個中大型的專案也是由這些大大小小的需求積累而成的。若你目前想作的單純就這麼簡單,那就不需要使用到分層的程式架構來實作。

在剛剛的月球任務中,我們能知道翠絲她要負責跟NASA要取距離資訊。在一般的任務中,可能一次的請求要再分拆成多個小任務,例如翠絲除了要跟NASA取得資料,也要跟某天文台溝通,這時她一個人可能就忙了。所以在 Clean Swift 中有提到,可以讓 Interactor 別這麼忙,當翠絲太忙時,應該要給她一些人力!一般公司情況是否也是如此?所以在 Clean Swift 中,Interactor 可以在拆成多個 Worker 來工作,一個 Worker 就只作一件事。翠絲要作的,便是管理這些工作人員了。

 

 

Clean Swift 的每個程式的依賴關係就是如此,若能理解這個觀念,既使是 MVP 跟 MVVM 也是能很快的適應它。

最後則放上實際的程式架構流程圖,有機會下次見。

 

 

Morris Mao