Подтвердить что ты не робот

Зачем нам нужны отдельные файлы .swift для каждого класса?

Интересно, можете ли вы ответить на очень простой вопрос для начинающих. Im работает через учебник Cocoa + Swift на Lynda и Im немного запутался в классах/объектах.

В принципе, я хочу знать, почему мы должны создать новый быстрый файл для каждого нового класса, который мы создаем.

Насколько я знаю, вы можете создать новый класс в любом файле .swift в проекте. Мой вопрос: зачем нам постоянно создавать файлы .swift для каждого нового класса.

Мне интересно, почему нет только одного .swift файла, называемого AllClasses.swift, который вы можете создать, в частности, следующие классы:

В 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.

Это идиотский вопрос, но еще одно препятствие, которое может сделать объектную ориентацию твердой концепцией, чтобы я мог полностью понять.

4b9b3361

ОТВЕТЫ

Ответ 1

Возможно, я могу объяснить это несколько забавным способом:

В начале не было понятия файлов, и весь код был в одном объекте. Код внутри таких объектов ссылался на номера строк. Поскольку все было в одном месте, было легко найти то, что вы хотели, хотя программы были небольшими. Это было лучше, чем перфолента, и поэтому было много радости. Мы должны что-то делать с загрузкой с кассеты.

Но потом кто-то обнаружил, что вы можете разбить код на отдельные части, называемые модулями, которые были такими же, как и программное обеспечение, получило больше. Человек мой жесткий диск 10 МБ огромен. Каждый модуль был специалистом и мог обращаться к другим специалистам. Это упростило навигацию вашего кода. Было много радости.

Но тогда кто-то обнаружил объектно-ориентированную (OO) и файлы были дешевыми. Программы были настолько большими, что люди с трудом находили этот класс, который смоделировал воздушную скорость африканского ласточки в этом многоклассовом файле, состоящем из 10000+ строк, возможно, настало время начать каждый класс в собственном файле. Излишне говорить, что было много радости.

Затем программное обеспечение стало настолько большим, что кто-то обнаружил источник управления, что было наиболее важно, когда команда кодирования писали все медитированные на части программного обеспечения. Безумие обеспечило братство, чье неосторожное стремление написать программу в одном файле из 30 000 строк (исследование африканских ласточек выросло до включения европейских ласточек) даже с OO, только привело к <сильному > конфликту линии после конфликта строк во время попыток проверить изменения в системе управления версиями. На костре было много горения. Позднее откровения приводят к разрыву кода во многих текстах или файлах, чтобы избежать линчевания.

  • Таким образом, нет никакого правила говорить, что у вас должен быть один файл для каждого класса, но его хорошая практика заключается в том, что ваша программа растет до разумного размера или сложности, что навигация и обслуживание вашего кода станут если вы этого не сделаете.
  • Это становится более важным при работе с командой, в которой число авторов, работающих одновременно на любом заданном файле, увеличивается вероятность возникновения конфликта исходного кода.

Я считаю, что монахи сейчас изучают свои любимые цвета и столичные страны.

Ответ 2

Некоторые причины:

  • Инкапсуляция/Контроль доступа. Плохая практика состоит в том, чтобы содержать несколько классов в одном файле, так как вы сможете получить доступ к каждой переменной/методу из этого исходного файла, даже если это отмечено как личное, как указано в Документация Apple:

Частный доступ ограничивает использование сущности своим собственным определением исходный файл. Используйте частный доступ, чтобы скрыть сведения о реализации определенную функциональность.

  1. Разделение ваших классов в отдельных файлах помогает компилятору строить быстрее. Когда был выпущен компилятор Swift 1.2, были добавлены инкрементные сборки, чтобы ускорить время сборки. Файлы, которые не редактируются, не компилируются в следующей сборке:

Инкрементные сборки. Исходные файлы, которые были изменены, больше не будут быть перекомпилирован по умолчанию, что значительно улучшит сборку раз для большинства распространенных случаев. Большие структурные изменения вашего кода может потребоваться пересортировать несколько файлов.

  1. Написание кода хорошо организовано. Вместе с правильным определением ответственности ваших классов (divide and conquer), которые помогут вам (и вашим товарищам по команде, если они есть) понять, кто что делает и где. И, как прокомментировано в других ответах, упростить отслеживание управления исходным кодом.

Ответ 3

Вам не нужно определять только один класс для каждого файла, но я бы предложил сделать это. Недавно я работал над проектом для клиента, где в некоторых исходных файлах было несколько классов, а некоторые классы были определены в файлах, имена которых не совпадали с именами классов. (Это было в Objective-C, поэтому каждый "файл" был действительно парой файлов, заголовочным файлом .h и файлом реализации .m, но логически они были такими.)

Это сбивало с толку как h * ll, и я потратил немало времени на то, чтобы найти вещи.

Определение одного класса для каждого файла и совпадение имен файлов и классов - это хорошее соглашение. Это похоже на то, что каждый школьный предмет в отдельном связующем. Когда вам нужно найти класс, вы точно знаете, какой файл открыть, чтобы его найти.

Ответ 4

Я также проголосую +1 за ваш вопрос и за верхние ответы.

Как новичок, я действительно согласен, что получить классы и концепции наследования сложно.

Но верьте, что гораздо лучше обрабатывать код в отдельных документах, возможно, используя концепцию MVC, вместо того, чтобы иметь этот код в одном массивном документе.

Мой собственный опыт, он очищает облака вашего кода.

Ответ 5

Как хорошая практика:

Если классы не связаны, длинны или используются независимо от других несвязанных классов, то они должны быть в отдельных файлах.

Однако, если классы тесно связаны друг с другом и не являются длинными, они могут находиться в одном файле.

Этот пост также затрагивает эту тему.