Организация исходных файлов Objective-C

Question

В Java мы организуем файлы в пакетах, Clojure имеет пространства имен, а Ruby имеет модули.
Как организовать файлы Objective-C?какие-либо соглашения / лучшие практики существуют?

В XCode все идет под каталогом "classes".

Answer 1

1. Что я обычно делаю, так это устанавливаю физические папки (и группы в XCode) для файлов и добавляю их в проект, откуда они находятся. Оттуда вы можете группировать файлы логически, как вы хотите. По умолчанию он создает файл в той же папке Classes, и мне трудно ориентироваться при работе с внешним клиентом контроля версий.

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

3. Для уникальности вы можете попробовать добавить префикс к папкам или группам классов.

Answer 2

Я просто организую вещи в XCode. Группируйте файлы соответствующим образом. Да, все заканчивается в каталоге Classes.

Answer 3

Мы используем MVC на всех проектах, кроме самых маленьких. Поэтому в папке «Классы» мы начинаем с добавления трех папок: Модель, Вид и Контроллер. В этих каталогах мы можем создавать подпапки, сгруппированные по функциональности с приложением (контроллеры для различных подразделов и т. Д.). Вы можете добавлять файлы непосредственно в Xcode или в сами папки. Аналогично, у нас есть каталог ресурсов, обычно в том же каталоге, что и файл .xcodeproj, и в этих папках находятся изображения, перья, аудио и т. Д.

Конечно, вышеописанное просто описывает стратегию организации на основе диска. Поскольку Objective-C по-прежнему C, вы можете создавать библиотеки и заголовочные файлы для API, которые вы хотите экспортировать. Вы также можете использовать категории. Многие из наших проектов ссылаются на каталог / Common, который находится вне папки проекта (а в разделе Common у нас есть Model, View, Controller и т. Д.). Иногда мы копируем файлы из Common в проект, если рассчитываем внести в них существенные изменения, которые мы не хотим, чтобы другие проекты наследовали.