浅谈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即可。
总结
以上的协议命名方式我认为是可以逻辑自洽的，也是我们团队目前在实行的一种统一的协议命名规范，对于代码可读性肯定是有帮助的。总之，不管命名的方式如何，只要保证逻辑自洽，统一规范都是可以的。