命名为现有对象添加扩展名的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源文件是什么？

Answer 1

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

String+UTF8Data.swift

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

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

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

Answer 2

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

 StringExtensions.swift 

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

Answer 3

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

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

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

Answer 4

如果你有一个团队同意的通用和其他增强的集合，将它们作为一个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。

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