命名Swift文件以向现有对象添加扩展名的最佳实践是什么？

如语言规范中所述，可以使用扩展将扩展添加到现有的Swift对象类型。

结果，可以创建扩展，例如：

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

但是，包含此类扩展名的Swift源文件的最佳命名做法是什么？

过去，惯例是extendedtype+categoryname.m用于Objective-C指南中讨论的Objective-C类型。但是Swift示例没有类别名称，并且调用它String.swift似乎不合适。

所以问题是：给定以上String扩展名，swift源文件应调用什么？

我看到的大多数示例都模仿了Objective-C方法。上面的示例扩展为：

String+UTF8Data.swift

优点是命名约定使您易于理解它是扩展名以及正在扩展哪个Class的名。

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

xxxable.swift对于仅定义方法的协议或扩展，使用Java 使用的方法行之有效。但是同样，上面的示例定义了一个属性，因此在UTF8Dataable.swift语法上没有太多意义。

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

StringExtensions.swift

我为要扩展的每个类创建一个文件。如果您对所有扩展名使用单个文件，它将很快变成丛林。

StringExtensions.swift在添加过多内容以将文件拆分为诸如String+utf8Data.swift和之前，我更喜欢String+Encrypt.swift。

还有一件事，将相似的文件合并为一个文件，将使您的构建更快。请参阅优化快速构建时间

如果您有一组团队同意的通用和其他增强功能，请将它们作为Extensions.swift合并在一起，作为Keep-It-Simple一级解决方案。但是，随着您的复杂性增加，或者扩展变得越来越复杂，需要一个层次结构来封装复杂性。在这种情况下，我将以示例的方式推荐以下做法。

我有一堂课，与我的后端对话，叫做Server。它开始变得越来越大，可以覆盖两个不同的目标应用程序。有些人喜欢一个大文件，但在逻辑上只是扩展名。我的首选是使每个文件都相对较短，因此我选择了以下解决方案。 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），但是就我看来，就隔离接口而言，这是一个干净的解决方案。

我认为这种方法对于外部指定的类以及您自己的类都同样有效。

为什么还要辩论？我是否应该将所有子类放入一个名为_Subclasses.swift的文件中。我觉得不是。Swift具有基于模块的名称间隔。扩展一个众所周知的Swift类需要一个特定于其目的的文件。我可能会有一个大团队来创建一个UIViewExtensions.swift文件，该文件没有任何目的，并且会使开发人员感到困惑，并且很容易在无法构建的项目中进行复制。Objective-C命名约定可以正常工作，并且在Swift拥有真实姓名间隔之前，这是最好的选择。

与其在整个地方添加我的评论，不如在一个答案中显示所有评论。

就我个人而言，我采用了一种混合方法，既提供了良好的可用性，又提供了清晰度，同时也不会弄乱我要扩展的对象的API表面积。

例如，任何有意义的可用于任何字符串的东西都将输入StringExtensions.swift诸如trimRight()和removeBlankLines()。

但是，如果我有一个扩展功能，例如formatAsAccountNumber()它不会在该文件中，因为“帐户号”并不是自然适用于任何/所有字符串的内容，并且仅在帐户范围内才有意义。在那种情况下，如果有几种类型/方式实际格式化它，我会创建一个名为Strings+AccountFormatting.swift甚至可能Strings+CustomFormatting.swift带有formatAsAccountNumber()函数的文件。

实际上，在最后一个示例中，我一开始就积极劝阻我的团队不要使用此类扩展程序，而是鼓励使用诸如此类的扩展程序，AccountNumberFormatter.format(String)因为它根本不涉及StringAPI表面积，应该这样做。例外是，如果您在使用扩展名的文件中定义了该扩展名，但是无论如何它就不会拥有自己的文件名。

我更喜欢用a +强调它包含扩展的事实：

String+Extensions.swift

如果文件太大，则可以出于各种目的将其拆分：

String+UTF8Data.swift

String+Encrypt.swift