在日常的开发中,协议的命名一直是颇耗心力的一件工作,不知道怎么详细的给协议命名,所以通常都是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

假如完成者是某个笼统实体,那么协议命名以名词来命名,比方**SequenceViewRepository

一个很显然的例子,便是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来结束,比方 ComparableCodableCachable

以下是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