为什么我们需要为每个class级单独的“.swift”文件？
想知道如果你能为我回答一个非常基本的初学者问题。 我正在通过Lynda上的Cocoa + Swift教程，对类/对象有点困惑。
基本上，我想知道为什么我们必须为每个创build的新类创build一个新的swift文件。
据我所知，你可以在项目的任何.swift文件中创build一个新的类。 我的问题是，为什么我们必须不断地为每个新类创build.swift文件。
我想知道为什么不只有一个名为AllClasses.swift的 .swift文件可以创build所有类，例如：
在AllClasses.swift中是以下代码：
Class FirstClass : NSObject Class SecondClass : NSObject Class ThirdClass : NSObject Class FourthClass : NSObject 正如所反对的：
在FirstClass.swift中是以下代码：
Class FirstClass : NSObject
在SecondClass.swift中是以下代码：
Class SecondClass : NSObject
在ThirdClass.swift中是以下代码：
Class ThirdClass : NSObject
在FourthClass.swift中是以下代码：
Class FourthClass : NSObject
我只是想知道，为什么我们需要将不同的代码分离成文件，如果可以从项目的任何区域调用。 在Mac应用程序的情况下，似乎几乎所有的东西都可以在AppDelegate.swift文件中完成。
这是一个杞人忧天的问题，但是另一个可能使面向对象的障碍成为一个难以理解的概念。
也许我可以用一种有趣的方式来解释它：
一开始没有文件的概念，所有代码都在一个实体中。 这些实体内的代码由行号引用。 因为一切都在一个地方，即使节目很小，也很容易find你想要的东西。 这比胶带好，所以有很多欢乐。 尽pipe如此，我们还是要做一些关于从卡带装载的东
但是后来有人发现你可以把代码分解成不同的模块 ，就像软件越来越大一样 。 我的10MB硬盘是巨大的。 每个模块都是专家 ，可以打电话给其他专家。 它使您的代码更易于浏览 。 有很多欢乐。
但是后来有人发现了面向对象 （OO），文件很便宜。 程序非常庞大，现在人们很难find这样一个模拟非洲燕子空速的class级， 这个class级包含了10000多行文件，也许是时候开始把每个class级放在自己的档案中。 毋庸置疑，有许多欢乐。
那么软件变得如此之大，以至于有人发现了源代码pipe理 ，当一组编码人员都在软件上冥想的时候，这是最重要的。 疯狂保证了这样的兄弟情谊，他们不顾一切地努力用一个三万多行的文件（对非洲燕子的研究已经发展到包括欧洲燕子）写了一个程序，甚至是OO，只是在试图检查变化时在行冲突后导致冲突进入源代码pipe理系统 。 这桩股票燃烧得很厉害。 后来的启示导致将代码分解成许多文本或文件是避免私刑的方式。
- 总之，没有规则说你必须每个类都有一个文件，但是如果你的程序增长到任何合理的大小或复杂度，那么你的代码的导航和维护将成为一个问题不要。
- 与团队一起工作变得更加重要，因为在任何给定文件上同时工作的作者数量，源代码提交冲突的可能性上升。
我相信僧侣现在正在研究他们最喜欢的颜色和国家的首府城市。
您不必为每个文件定义一个类，但我会build议这样做。 我最近在一个客户的项目中工作，那里的某些源文件中有几个类，并且在名称与类名不匹配的文件中定义了一些类。 （这是在Objective-C中，所以每个“文件”实际上是一对文件，一个.h头文件和一个.m实现文件，但逻辑上它们是一个。）
这是令人困惑的，我浪费了相当多的时间摸索着找东西。
为每个文件定义一个类并使文件名和类名完全匹配是一个很好的约定。 这就像每个学校在一个单独的活页夹中的主题。 当你需要find一个class级时，你确切地知道要打开哪个文件来find它。
一些原因：
- 封装/访问控制 。 在Apple文档中指出，在同一文件中包含多个类是不好的做法，因为即使该文件被标记为私有，也可以从该源文件访问每个variables/方法：
私人访问限制了一个实体对自己的定义源文件的使用。 使用私人访问来隐藏特定function的实现细节。
- 将你的类分离成不同的文件可以帮助编译器更快地构build 。 当Swift 1.2编译器发布时，引入了增量构build来加快构build时间。 未编辑的文件不会在您的下一个版本中再次编译：
增量构build – 未更改的源文件将不再被默认重新编译，这将大大改善大多数常见情况下的构build时间。 对代码进行更大的结构更改可能仍然需要重build多个文件。
- 编写代码组织良好 。 连同正确定义你的课程的责任（ 分而治之 ），这将帮助你（和你的队友，如果有的话）了解谁做什么和在哪里。 而且，正如其他答案中所评论的那样，使您的源代码pipe理pipe理更容易跟踪。
我也对你的问题投了+1，并为上面的答案。
作为一个新手，我真的很同意，很难获得类和inheritance的概念。
但是，相信在单独的文档中处理代码要好得多，也许使用MVC的概念，而不是将这些代码放在一个大规模的文档中。
我自己的经验，它清除了你的代码的云。
作为好的做法：
如果这些类是不相关的，冗长的或独立于其他不相关的类使用，那么它们应该在不同的文件中 。
但是，如果这些类彼此紧密耦合，并且冗长，那么它们可能在同一个文件中。
这篇文章也涉及到这个问题。