把代碼遷移到協調器上

做者：Soroush Khanlou，原文連接，原文日期：2017-4-25
譯者：Cwift；校對：Crystal Sun；定稿：CMB

這篇文章是 Coordinators（協調器）進階教程系列的第一篇。若是你沒有閱讀過原始的帖子及其後續，請務必首先查閱這些文章。該系列將涵蓋幾項進階的 Coordinator 使用技巧、疑點、常見問題以及其餘細碎的內容。讓咱們開始吧。

常有人問我，如何把一個使用 Storyboard 構建或者是使用純代碼編寫 ViewController 構建的應用重構成使用 Coordinators 的應用。只要方法正確，重構能夠逐步完成。即便重構未完成，你的應用仍舊能夠部署。

要實現這個目標，最好的作法是從根路徑出發，在 Coordinators 中稱之爲 「AppCoordinator」。AppDelegate 持有該 AppCoordinator，AppCoordinator 調度 App 能夠加載的全部 ViewController。

想要理解爲何從 App 的根路徑開始，能夠從反面來思考。若是從一些葉子流程開始（好比，一個 CheckoutCoordinator），那麼須要保持對該 Coordinator 的強引用，以防它被釋放。若是 Coordinator 被釋放，它內部的代碼就都不能執行了。因此，深刻一個 App 中去，若是咱們建立一個 Coordinator，必須讓某個對象長久地持有它。

有兩種方案能夠防止對象被釋放。第一種方案是使用靜態引用。由於系統裏可能只有一個 CheckoutCoordinator，因此很容易將其填充到一個全局變量中。雖然這種方案有效果，可是不是一個理想的選擇，由於全局變量阻礙了可測試性和靈活性。第二種方案是讓當前展現的 ViewController 持有 Coordinator。這將迫使當前的 ViewController 變得複雜一些，可是能夠下降 Coordinator 所管理的全部 ViewController 的複雜性。然而，這種關係本質上是有缺陷的。ViewController 是 Coordinator 的「孩子」，編程時，孩子們不該該不知道他們的父母是誰。相似於一個 UIView 持有了一個 UIViewController 的引用：這種事是不應發生的。

若是你遇到了必須從子流程開始的狀況，你可使用上述兩種方法之一。可是，若是能夠選擇，個人建議是從根路徑開始。

從根路徑開始的另外一個好處是認證流程一般更靠近 App 的根路徑。身份認證是一個很好的流程，能夠抽象成單獨的對象，很適合用來驗證 App 中的 Coordinator。

將 App 的 RootViewController 交付給 AppCoordinator 以後，你能夠對代碼進行 Commit/Pull Request/Code Review。由於其餘的 ViewController 仍在正常運轉，因此 App 能夠在這個未完工的狀態下繼續工做。基於這點，逐步改造，你能夠將更多的 ViewController 交付給 Coordinator。將每一個「流程」都交付給 Coordinator 以後，你能夠提交代碼或者建立一個 pr，不會影響 App 的正常工做。正如最佳重構同樣，這些步驟只是移動代碼，有時根據須要建立新的 Coordinator。

一旦全部的場景切換都轉移到了 Coordinator 中，你就能夠開始下一步的重構了，例如將 iPhone 和 iPad 的 Coordinator 封裝到單獨的對象（而不是一個切換狀態的 Coordinator），讓子流程可複用，更好地依賴注入，這些均可以應用到你的新架構中。

本文由 SwiftGG 翻譯組翻譯，已經得到做者翻譯受權，最新文章請訪問 http://swift.gg。