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

AlB*_*lue 150 xcode objective-c ios swift

可以使用扩展向现有Swift对象类型添加扩展,如语言规范中所述.

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

extension String {
    var utf8data:NSData {
        return self.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)!
    }
}
Run Code Online (Sandbox Code Playgroud)

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

在过去,该公约是使用extendedtype+categoryname.m如在讨论了目标C型Objective-C的导向.但是Swift示例没有类别名称,并且调用它String.swift似乎不合适.

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

pic*_*ano 182

我见过的大多数例子都模仿了Objective-C方法.上面的示例扩展名为:

String+UTF8Data.swift

优点是命名约定使得它易于理解它是一个扩展,以及哪个类正在被扩展.

使用的问题Extensions.swift甚至StringExtensions.swift是不可能在不查看其内容的情况下通过其名称推断文件的目的.

使用xxxable.swiftJava 使用的方法可以用于仅定义方法的协议或扩展.但同样,上面的例子定义了一个属性,因此UTF8Dataable.swift没有多少语法意义.

  • 这个答案,<name> + <extention> .swift,确实是Xcode在为Xcode 8中的Core Data创建NSManagedObject子类时的方式.示例:Foo + CoreDataProperties.swift. (14认同)
  • 如果扩展实现多种方法怎么办? (3认同)
  • 虽然人们可以推断出命名约定扩展了什么,但 IHMO 是一种不必要的复杂化。而不是大量的 &lt;name&gt;+&lt;extention&gt;.swift 文件,我保留了一个 extensions.swift 文件,我通常用于每个项目。该文件在内部进行了组织,因此很容易找到扩展的特定类。 (2认同)
  • 尽可能做到描述性。例如,如果您具有Image的扩展名,其中包括应用滤镜的不同功能,则将其命名为Image + Filters.swift。可以对扩展功能的相关组使用不同的文件。将相关的事物组合在一起,但是将无关的事物分开。生活会很好。 (2认同)

Mik*_*rne 10

没有Swift惯例.把事情简单化:

StringExtensions.swift
Run Code Online (Sandbox Code Playgroud)

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

  • 这似乎并不特别重用. (9认同)
  • 与单个(或紧密耦合)的类扩展文件相比,它们服务于单个(或明确可关联的)目的.像"StringExtensions"这样的东西听起来像它可以包含从通用字符串清理到特定于应用程序的逻辑的所有内容 - 如果重用是一个问题,这可能不是最好的方法.可可命名约定倾向于功能,而不是实现.我认为"StringExtensions"表示后者.除了命名约定,我更喜欢接受的答案,当然在ObjC中,但在Swift中,由于模块,它似乎是更好的方法. (3认同)
  • 那讲得通。我更多地考虑的是一个不需要重用的单一应用程序。例如,假设我有一些不相关的字符串函数想要用作扩展——我可以创建一个文件并将所有这些函数放在那里,或者为每个函数创建一个文件。在这种情况下,我喜欢单个文件的简单性。但你的推理是合理的。谢谢。 (2认同)

Xys*_*Xys 8

我更喜欢+强调它包含扩展的事实:

String+Extensions.swift

如果文件太大,您可以针对每个目的拆分它:

String+UTF8Data.swift

String+Encrypt.swift


Daw*_*ong 5

我更喜欢StringExtensions.swift在添加太多内容之前将文件拆分为 和 之类的String+utf8Data.swift内容String+Encrypt.swift

另一件事是,将相似的文件合并为一个将使您的构建速度更快。请参阅优化 Swift 构建时间