命名为现有对象添加扩展名的Swift文件的最佳做法是什么?

如语言规范中所述,可以使用扩展为现有的Swift对象types添加扩展。

因此,可以创build扩展名,例如:

extension String { var utf8data:NSData { return self.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)! } } 

但是,包含这样的扩展名的Swift源文件的最佳命名实践是什么?

在过去,惯例是使用Objective-C指南中讨论的Objective-Ctypes的extendedtype+categoryname.m 。 但是Swift的例子没有一个类别名称,并且调用String.swift似乎不合适。

所以问题是:给定上面的String扩展名,应该调用swift源文件是什么?

我见过的大多数例子都模仿Objective-C的方法。 上面的示例扩展将是:

String+UTF8Data.swift

其优点是命名约定使得它容易理解,它是一个扩展,哪个类正在扩展。

使用Extensions.swift甚至StringExtensions.swift的问题在于,无法通过名称的内容来推断文件的用途。

Java使用的xxxable.swift方法对于仅定义方法的协议或扩展而言工作正常。 但是,上面的例子再一次定义了一个属性,所以UTF8Dataable.swift没有太多的语法意义。

没有Swift约定。 把事情简单化:

 StringExtensions.swift 

我为每个我正在扩展的课程创build一个文件。 如果您为所有扩展使用单个文件,它将很快变成丛林。

我的首选是将“Extension_”放在文件的开头。 (我把所有相关的扩展到同一个文件中。)

这样,所有扩展文件都按照字母顺序排列在我的应用程序目录和Xcode的导航器中。 当然,在航海家,我也可以把他们分组。

所以,与string相关的扩展将进入Extension_String.swift

如果你有一个团队同意的通用和其他增强的集合,将它们作为一个Extensions.swift集合在一起,可以作为Keep-It-Simple的一级解决scheme。 然而,随着复杂性的增长,或者扩展变得越来越复杂,需要一个层次来封装复杂性。 在这种情况下,我推荐以下做法。

我有一个课程,我的后端,称为Server 。 它开始扩大到涵盖两个不同的目标应用程序。 有些人喜欢一个大文件,但只是逻辑上与扩展分裂。 我的首选是保持每个文件相对较短,所以我select了以下解决scheme。 Server最初符合CloudAdapterProtocol并实施了所有的方法。 我所做的就是把协议变成一个层次结构,使其指向从属协议:

 protocol CloudAdapterProtocol: ReggyCloudProtocol, ProReggyCloudProtocol { var server: CloudServer { get set } func getServerApiVersion(handler: @escaping (String?, Error?) -> Swift.Void) } 

Server.swift我有

 import Foundation import UIKit import Alamofire import AlamofireImage class Server: CloudAdapterProtocol { . . func getServerApiVersion(handler: @escaping (String?, Error?) -> Swift.Void) { . . } 

Server.swift然后只是实现了核心服务器API来设置服务器和获取API版本。 真正的工作分成两个文件:

 Server_ReggyCloudProtocol.swift Server_ProReggyCloudProtocol.swift 

这些执行相应的协议。

这意味着你需要在其他文件中有导入声明(在这个例子中为Alamofire),但是在我看来,它是一个干净的解决scheme。

我认为这种方法与外部指定的类以及你自己的方法一样好。