在日常的开发中，协议的命名一直是颇耗心力的一件工作，不知道怎么详细的给协议命名，所以通常都是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 调集，所以咱们给该协议命名的时分，就应该是一个名词。

extension Array: RandomAccessCollection, MutableCollection {
    ...
}

Performed by → …ing

假如完成者要去做某些工作，那么协议命名要以ing结束，比方Loading, Generating, Coordinating。

以下是一个以名词命名的协议：ColorProvider，它是用来描绘色彩内容的一个接口。

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协议的事例：

public protocol Equaltable {
    static func == (lhs: Self, rhs: Self) -> Bool
}

关于该协议的完成者，需要去完成== 办法，来比较本身来判等，所以运用able 结束是十分适宜的。

Performed for → …delegate

假如完成者是为了其他的实体做某些工作，那么协议命名就以delegate 结束，比方CardCellActionDelegate…

这个的事例就多了，因为代理形式是咱们运用的设计形式中十分常见的一种，这儿就不做实例了。

Unable to identify → …protocol

实际的开发中仍是有许多协议难以分类，既然如此那就不再分类，直接在后面添加protocol即可。

总结

以上的协议命名办法我认为是能够逻辑自洽的，也是咱们团队目前在实施的一种一致的协议命名标准，关于代码可读性肯定是有协助的。总归，不管命名的办法怎么，只需确保逻辑自洽，一致标准都是能够的。

参阅

• Naming a Protocol in Swift
• Protocol types and naming
• API Design Guidelines