??原文鏈接
前言
本篇博客主要介紹
Swift 實踐方面的一個技巧，鏈式 UI 代碼。鏈式代碼在 Swift 中有著比 Objective-C 天然的優勢。而且通過 Swift
語言本身強大的特性，只需要很少的代碼就可以讓自己的 Swift 工程具有編寫鏈式 UI 代碼的能力。
緣由
先來回答一個問題，為什么要用鏈式代碼來寫
UI？答案就是，提高代碼可讀性。代碼可讀性的重要性在軟件工程的意義不必多說。而代碼可讀性可以從許多方面優化，比如，合適的縮進、正確的命名、清晰有邏輯的結構等等。鏈式
UI 代碼正是從清晰有邏輯的結構這點出發，提高代碼可讀性的一種方案。
在
iOS 開發中，我們每天都要 UI 代碼打交道。而在 UI 的實現方面，用 Storyboad 實現還是代碼實現，是 iOS
開發領域中一個永不停息的爭論。兩者各有優勢，關于這個的討論也不在本篇博客范圍內。不過無論是用何種形式寫 UI， 代碼或者 Storyboard,
如果整體的 UI 布局沒有一個清晰的分層和結構，那么維護起來都會吃力。本篇的重點在于介紹一種代碼風格，一個使用鏈式代碼來寫 UI
布局的代碼風格，而不在于講解如何將 UI 布局做得結構清晰
前置條件
有一些前置條件需要交代一下。接下來的介紹中，UI
布局通過代碼來完成，而且使用的是 AutoLayout 而非絕對布局。相信沒有人會用原生的 Autolayout API 來寫全部的 UI
吧，一般會選用一個封裝庫。博客下面的介紹以最常見的 Autolayout 封裝庫 SnapKit
來舉例，如果你的工程使用了別的庫，根據情況來修改相關的代碼即可。
核心代碼實現
先來分析一下 UI 布局代碼的結構。翻出一段使用代碼完成的 UI 布局代碼看一看，你會發現其中的一些特定的結構。
第一步肯定是會初始化一個 view，接下來通過一系列步驟完成需求：添加到父 view、添加視圖約束、配置屬性。在這接下來的三個步驟里，添加到父視圖這個步驟一定要在添加視圖約束這個步驟之前。至于配置 view 屬性這個步驟，在這兩個步驟之前或之后都沒有問題。
除了初始化 view 這個步驟，將其后的三個步驟抽取出來，做成三個通用的鏈式布局函數，將這三個函數使用 extension 機制擴展到 UIView 中。實現代碼如下：
以上就是完成鏈式 UI 布局的所有代碼。僅僅 20 多行代碼就完成了整個核心功能，是不是很棒？不需要引用任何第三方庫，只要將這段代碼拷貝到 Swift 工程中，你的工程馬上就有了寫鏈式 UI 代碼的能力。
來個樣例說明用法，比如，我們要在一個 view 中添加一個 label，這個 label 水平居中，它的 top 與父 view 的 top 相距 80。代碼如下：
那么這段樣例代碼有什么好處呢？首先，從這段代碼中，可以明顯看到
UI 布局的步驟，而且添加約束和配置 view 的具體邏輯代碼，被不同的 Closure
封裝起來。代碼的結構要比之前的寫法，代碼都用同一個縮進的代碼結構要更清晰一些。當定位到 UI
的問題后，可以根據問題是布局錯誤還是配置問題，直接去分析對應的代碼邏輯。
這樣的代碼還有一些別的好處，那就是 UI 配置相關代碼的復用性提高。來，針對上面的代碼的 config 部分做如下的修改:
完成與之前同樣功能的代碼，但是這里定義了一個類型為 (UILabel) ->
Void 的 Closure，并將其作為參數直接傳遞給了鏈式函數 config。想想，如果接下來新建一個名為 label2 的
UILabel，配置跟 label 一樣，那個它的 config 函數直接接收這個 labelConfiger 的 Closure
作為參數就可以完成配置。你可以能會問，如果這兩個 label 的文本值不一樣的時候怎么辦呢。這種情況，只需要將代碼改動如下
沒錯。作為鏈式代碼，config 函數可以多次對自身調用。不過需要注意的是，針對視圖的同一個屬性，后面調用的 config 函數會覆蓋掉前面的 config 函數里設置的狀態。
在 Swift 中，Closure 是可以被當做變量的，而且就連函數其實也是一種 Closure。所以，接下來就可以自由發揮啦~~
分析實現
來講解一下鏈式核心代碼的實現。 鏈式函數的關鍵就在于返回值類型與自身相同。
由于是
UI 相關，那么首先是對 UIView 這個視圖父類做擴展。adhere 這個函數沒啥可說的，就是講自身添加到通過參數傳入的父視圖上。接下來是
layout 這個布局函數實現，由于是使用 SnapKit，而且具體的布局邏輯不同的視圖也不一樣。所以將使用 SnapKit
布局時的關鍵邏輯代碼以 Closure 閉包參數的形式傳入。這里比較難理解的是 config 函數的實現，可以看到這里定義了一個名為
ViewChainable 的協議，然后對這個協議做了一個擴展，并讓 UIView 實現了這個協議。這么做的原因在于，為了讓 config
函數的閉包參數在實際使用中，閉包的第一個參數類型可以具體到 UIView 的不同子類上。拿上面的例子來說，UILabel 的實例在調用
config 函數時，所需的閉包參數類型就是 (UILabel) -> Void 而不是 (UIView) -> Void。
優化
不知不覺文章已經很長了，不過還是希望你讀下去。接下來是對上面的鏈式核心代碼的優化。
由于上面的實現是直接針對
UIView 做了方法擴展，這在實際的工程中會碰到一個問題：命名沖突。舉例來說，如果下一個版本的 SDK 更新后，UIKit 給 UIView
新增了一個 adhere 函數，參數和返回值類型和上面的定義完全一樣，那如果發生這種情況，就只能修改自己之前的代碼了。
Objective-C
時代的一個通行做法是對系統庫的擴展方法加一個至少三個字符的前綴，這樣函數名字就變成了這樣：xxx_adhere
。當然你可以按照這種形式，給之前的鏈式 UI 函數名字都加上一個前綴，這么做是沒有任何問題的。可是在 Swift 的世界里，有著更 Swifty
的實現形式，我在之前的博客文章 Swift 命名空間形式擴展的實現 中具體介紹這種形式的實現方式。那篇文章里提到的 HandOfTheKing
這個工程，里面已經包含了命名空間形式的鏈式 UI 代碼實現。需要注意的是，在最近的一次更新里，我把這個項目的命名空間前綴由之前的 hk 改為了
hand，hk 用起來總感覺跟香港有關。哎，誰讓命名是編程世界的一大難題呢~~下面貼出具體實現的代碼（這里不包含命名空間的實現）
改成這個之后，之前的 label 的代碼就變成了下面的風格:
進階
如果你對響應式編程感興趣，你會發現 RxSwift 這個框架和上面的鏈式布局代碼簡直是絕配。RxSwift 這個庫本身也是支持很多鏈式調用的。關于 RxSwift，這又是另外一個大坑了，本篇就不多講了。
