淺談Swift中協議命名的規範
在日常的開發中，協議的命名一直是頗耗心力的一件事情，不知道如何具體的給協議命名，所以通常都是XXX+Protocol 的命名規則，雖然不會出錯，但是並不能信達雅的傳達出這個協議的作用，無法代碼即註釋，可讀性略差。
而關於協議命名這類的問題，其實是沒有一個大一統的觀點的，比如使用tab還是使用space 來進行縮進，但是這類問題的不同觀點會導致團隊內部出現一些爭執，雖然説沒有一個必然正確的方式，但是在團隊中共享一個約定是非常必要的！保證這種一致性可以提高代碼的可讀性。
那麼如何去給協議命名呢？原則上只要邏輯自洽即可。在Swift API design guidelines中，有兩種給協議命名的描述：
- Protocols that describe what something is should read as nouns (e.g. Collection).
- Protocols that describe a capability should be named using that suffixes able, ible, or ing(e.g. Equatable, ProgressReporting).
以此來衍生，我們可以總結出以下幾種命名的規則
Something → nouns
如果實現者是某個抽象實體，那麼協議命名以名詞來命名，比如**Sequence，View，Repository。
一個很顯然的例子，就是Swift中的**Array**, **Set** 這些集合類型，因為它們都具備集合的特性，都屬於**Collection 集合，所以我們給該協議命名的時候，就應該是一個名詞。
swift
extension Array: RandomAccessCollection, MutableCollection {
...
}
Performed by → …ing
如果實現者要去做某些事情，那麼協議命名要以ing結尾，比如Loading, Generating, Coordinating。
以下是一個以名詞命名的協議：ColorProvider，它是用來描述顏色內容的一個接口。
swift
protocol ColorProvider {
var foregroundColor: UIColor { get }
var backgroundColor: UICOlor { get }
}
這裏使用名詞命名顯然是有些不合適的，因為這個類型並不是某個抽象實體，而是屬於要去做某些事情的類別，這個類型提供了顏色，所以它應該被命名為**ColorProviding。同樣的，在我們的項目中，經常會使用到以下類型名：Manager, Coordinator 以及 Generator，都是使用動詞轉化為名詞當作類型名，但是如果用作協議命名的話，將動詞轉化為進行時會更加合適：Managing, Coordinating, Generating。
Performed on → …able/ible
如果是對實現者做某些事情，那麼協議命名以able或者ible來結尾，比如 Comparable，Codable，Cachable。
以下是Equalble協議的案例：
swift
public protocol Equaltable {
static func == (lhs: Self, rhs: Self) -> Bool
}
對於該協議的實現者，需要去實現== 方法，來比較自身來判等，所以使用able 結尾是非常合適的。
Performed for → …delegate
如果實現者是為了其他的實體做某些事情，那麼協議命名就以delegate 結尾，比如CardCellActionDelegate…
這個的案例就多了，因為代理模式是我們使用的設計模式中非常常見的一種，這裏就不做實例了。
Unable to identify → …protocol
實際的開發中還是有很多協議難以分類，既然如此那就不再分類，直接在後面添加protocol即可。
總結
以上的協議命名方式我認為是可以邏輯自洽的，也是我們團隊目前在實行的一種統一的協議命名規範，對於代碼可讀性肯定是有幫助的。總之，不管命名的方式如何，只要保證邏輯自洽，統一規範都是可以的。