为什么每个类都需要单独的".swift"文件?

Wav*_*mer 23 ios swift

想知道你是否能够为我回答一个非常基本的初学者问题.我正在研究Lynda上的Cocoa + Swift教程,我对类/对象有点困惑.

基本上,我想知道为什么我们必须为我们创建的每个新类创建一个新的swift文件.

据我所知,您可以在项目的任何.swift文件中创建一个新类.我的问题是,为什么我们必须不断为每个新类创建.swift文件.

我想知道为什么不只有一个名为AllClasses.swift的.swift文件可以创建所有类,例如:

AllClasses.swift中是以下代码:

Class FirstClass : NSObject
Class SecondClass : NSObject
Class ThirdClass : NSObject
Class FourthClass : NSObject
Run Code Online (Sandbox Code Playgroud)

正如反对:

FirstClass.swift中是以下代码:

Class FirstClass : NSObject
Run Code Online (Sandbox Code Playgroud)

SecondClass.swift中是以下代码:

Class SecondClass : NSObject
Run Code Online (Sandbox Code Playgroud)

ThirdClass.swift中是以下代码:

Class ThirdClass : NSObject
Run Code Online (Sandbox Code Playgroud)

FourthClass.swift中是以下代码:

Class FourthClass : NSObject
Run Code Online (Sandbox Code Playgroud)

我只是想知道为什么我们需要将不同的代码分成文件,如果它可以从项目的任何区域内调用.对于Mac应用程序,似乎几乎所有内容都可以在AppDelegate.swift文件中完成.

这是一个愚蠢的问题,但另一个可能使面向对象的障碍成为我完全掌握的难题.

Mic*_*kyD 31

也许我可以用一种有趣的方式解释它:

一开始,没有文件概念,所有代码都在一个实体中.这些实体中的代码由行号引用.因为一切都在一个地方很容易找到你想要的东西,即使程序很小.它比打孔磁带更好,因此有很多欢乐.我们必须做一些关于从卡带装载的事情.

但后来有人发现你可以将代码分解成称为模块的独立部分,这与软件变得越来越.男人我的10MB硬盘是巨大的. 每个模块都是专家,可以打电话给其他专家.它使您的代码更容易导航.有很多欢乐.

但后来有人发现面向对象(OO)并且文件很便宜.程序是如此之大,现在人们很难找到那个模拟非洲燕子空速的课程,课程包含10,000多行的多类文件,也许是时候开始将每个课程放在自己的文件中了.不用说,有很多欢乐.

然后,软件变得如此之大,以至于有人发现了源代码控制,当编码团队在一个软件上进行冥想时,这是最重要的.疯狂确保了兄弟情谊,他们不小心努力将一个项目写成一个包含30,000多行的文件(关于非洲燕子的研究已经发展到包括欧洲燕子),即使有OO,也只是在尝试检查变化时导致线间冲突进入源控制系统.赌注有很多燃烧.后来的启示导致将代码分解成许多文本或文件是避免私刑的方法.

  • 总之,没有规则说每个类必须有一个文件,但这是一个很好的做法,主要是因为你的程序增长到任何合理的大小或复杂性,导致和维护你的代码会成为一个问题,如果你不要.
  • 在与团队合作时变得更加重要,因为在任何给定文件上并发工作的作者数量,源代码提交冲突的可能性就会增加.

我相信僧侣现在正在研究他们最喜欢的颜色和国家的首都城市.

  • 我非常喜欢读这篇文章,感谢您花时间帮助我. (3认同)
  • 可爱的。作为对 @noobsmcgoobs 评论的回应,Swift 根本不使用标头。(如果您创建混合 Swift/Objective-C 程序,编译器确实会为您的 Swift 文件生成 Objective-C 标头,但这是另一个主题。) (2认同)

atx*_*txe 10

一些原因:

  1. 封装/访问控制.在同一个文件中包含多个类是不好的做法,因为您可以从该源文件访问每个变量/方法,即使它被标记为私有,如Apple文档中所述:

专用访问将实体的使用限制在其自己的定义源文件中.使用私有访问隐藏特定功能的实现细节.

  1. 在单独的文件中分离您的类有助于编译器更快构建.当Swift 1.2编译器发布时,引入了增量构建以加快构建时间.未编辑的文件不会在下一次构建时再次编译:

增量构建 - 默认情况下将不再重新编译未更改的源文件,这将显着缩短大多数常见案例的构建时间.对代码进行较大的结构更改可能仍需要重建多个文件.

  1. 编写良好的代码.与正确定义您的课程(分而治之)的责任相结合,这将有助于您(以及您的队友,如果有的话)了解谁在做什么,在哪里做什么.并且,正如其他答案所述,使您的源代码管理更易于跟踪.


Dun*_*n C 9

您不必为每个文件定义一个类,但我建议这样做.我最近为一个客户开发了一个项目,其中一些源文件中有几个类,并且在文件中定义了一些类,这些类的名称与类名不匹配.(这是在Objective-C中,所以每个"文件"实际上是一对文件,一个.h头文件和一个.m实现文件,但逻辑上它们是一个.)

这让人感到困惑,我浪费了相当多的时间在寻找事情上摸索着.

为每个文件定义一个类并使文件名和类名完全匹配是一个很好的约定.这就像让每个学校科目都在一个单独的活页夹中.当您需要找到一个类时,您确切地知道要打开哪个文件来查找它.


小智 5

对于您的问题和最高答案,我也将+1投票。

作为一个新手,我真的同意很难获得类和继承概念。

但是,相信最好在单独的文档中处理代码,也许使用MVC概念,而不是在一个庞大的文档中处理这些代码。

以我自己的经验,它清除了代码的阴云。