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