Why do we need separate ".swift" files for each class?

Question

Wondering if you might be able to answer a very basic beginner question for me. I’m working through the Cocoa + Swift tutorial on Lynda and I’m a little confused about classes/objects.

Basically, I want to know why we have to create a new swift file for each new class we create.

As far as I know, you can create a new class within any .swift file in the project. My question is, why do we have to continually keep creating .swift files for each new class.

I’m wondering why there isn’t just one .swift file called AllClasses.swift that you can create all the classes in, for instance:

Within AllClasses.swift is the following code:

Class FirstClass : NSObject Class SecondClass : NSObject Class ThirdClass : NSObject Class FourthClass : NSObject 

As Opposed to:

Within FirstClass.swift is the following code:

Class FirstClass : NSObject 

Within SecondClass.swift is the following code:

Class SecondClass : NSObject 

Within ThirdClass.swift is the following code:

Class ThirdClass : NSObject 

Within FourthClass.swift is the following code:

Class FourthClass : NSObject 

I just want to know why we need to separate different code into files if it can be called from within any area of the project. In the case of a Mac application, it seems like almost everything could be done from within the AppDelegate.swift file.

This is a moronic question, but another hurdle that may be making object orientation a hard concept for me to fully grasp.

Answer 1

Maybe I can explain it in a somewhat amusing way:

In the beginning there was no concept of files and all code was in a single entity. Code within such entities was referenced by line numbers. Because everything was in one place it was easy to find what you wanted, even though programs were small. It was better than punch tape and so there was much rejoicing. We gotta do something about loading from cassette though.

But then someone discovered you could break up the code into separate parts called modules which was just as well as software was getting bigger. Man my 10MB hard drive is huge. Each module was a specialist and could call other specialists. It made your code easier to navigate. There was much rejoicing.

But then someone discovered object-orientation (OO) and files were cheap. Programs were so large now people were having a hard time finding that class that modelled the airspeed of an African Swallow in that multiple-class-containing file of 10000+ lines that maybe its time to start putting each class in its own file. Needless to say there was much rejoicing.

Then software had become so large that someone discovered source control which was most important when a team of coding scribes all meditated on a piece of software. Madness ensured for the brotherhood whose careless endeavour to write a program in one file of 30,000+ lines (research on African Swallows had grown to include European Swallows) even with OO, only lead to line conflict after line conflict during their attempts to check in changes into the source control system. There was much burning at the stake. Later revelations lead to breaking up the code into many texts or files was the way to avoid a lynching.

• In summary, there is no rule to say you must have one file per class but its a good practice to do so mainly in the event your program grows to any reasonable size or complexity that navigation and maintenance of your code would become an issue if you do not.
• It becomes more important when working with a team where as the number of authors working concurrently on any given file, the probability of source code commit conflict rises.

I believe the monks are studying their favourite colours and capital cities of countries now.

Answer 2

Some reasons:

1. Encapsulation / Access Control. It's a bad practice to contain several classes in the same file as you'll be able to access every single variable / method from that source file even if that is marked as private, as stated in Apple documentation:

Private access restricts the use of an entity to its own defining source file. Use private access to hide the implementation details of a specific piece of functionality.

2. Separating your classes in separate files helps the compiler to build faster. When Swift 1.2 compiler was released, incremental builds were introduced to speed up the build times. Files that are not edited are not compiled again on your next build:

Incremental builds — Source files that haven’t changed will no longer be re-compiled by default, which will significantly improve build times for most common cases. Larger structural changes to your code may still require multiple files to be rebuilt.

3. Writing code well organized. Together with defining correctly the responsabilities of your classes (divide and conquer) that will help you (and your teammates, if any) to understand who does what and where. And, as commented in other answers, to make your source control management easier to track.