Вопрос 1: Объектно-C-эквивалент пакетов Java?
Objective-C не имеет эквивалента пакетам Java или пространствам имен C ++. Частично это связано с тем, что Objective-C изначально был очень тонким слоем времени поверх C, и добавил объекты на C с минимальной суматохой. К сожалению, для нас сейчас конфликты имен - это то, с чем нам приходится иметь дело при использовании Objective-C. Вы выигрываете, вы теряете некоторые ...
Одно небольшое разъяснение (хотя это не так много для утешения) состоит в том, что Objective-C на самом деле имеет два плоских пространства имен - один для классов и один для протоколов (например, интерфейсы Java). Это не решает конфликтов имен, но это означает, что у вас может быть протокол и класс с тем же именем (например, <NSObject> и NSObject ), где последний обычно принимает («реализует») первый. Эта функция может предотвратить распространение шаблона «Foo / FooImpl» на Java, но, к сожалению, это не помогает в конфликтах классов.
Вопрос 2: Как [имя] и организовать классы Objective-C?
Именование
Следующие правила являются субъективными, но они являются достойными рекомендациями по назначению классов Objective-C.
- Если ваш код не может быть запущен другим кодом (это не фреймворк, плагин и т. Д., А приложение или инструмент конечного пользователя), вам нужно избегать конфликтов с кодом, с которым вы ссылаетесь. Часто это означает, что вы можете обойтись без префикса вообще, пока используемые вами фреймворки / плагины / пучки имеют собственные пространства имен.
- Если вы разрабатываете «компонентный» код (например, фреймворк, плагин и т. Д.), Вы должны выбрать префикс (надеюсь, тот, который является уникальным) и документировать, как вы его используете, видимо, что другие знают, чтобы избежать потенциальных конфликтов. Например, CocoaDev wiki «реестр» является де-факто открытым форумом для вызова «dibs» на префикс. Однако, если ваш код является чем-то вроде внутренней структуры компании, вы можете использовать префикс, который еще кто-то делает, до тех пор, пока вы не используете что-либо с этим префиксом.
организация
Организация исходных файлов на диске - это то, что многие разработчики Cocoa, к сожалению, замаскируют. Когда вы создаете новый файл в Xcode, по умолчанию используется каталог проекта, рядом с вашим файлом проекта и т. Д. Лично я добавляю источник приложения в исходный код, тестовый код (OCUnit и т. Д.) В test / , все ресурсы (Файлы NIB / XIB, Info.plist, изображения и т. Д.) В ресурсах / и т. Д. Если вы разрабатываете сложный проект, то также может быть хорошим решением для группировки исходного кода в иерархии каталогов на основе функциональности. В любом случае хорошо организованный каталог проектов облегчает поиск того, что вам нужно.
Xcode действительно не интересует, где находятся ваши файлы. Организация на боковой панели проекта полностью не зависит от расположения диска - это логическая (не физическая) группировка. Вы можете организовать, как вам нравится, на боковой панели, не затрагивая местоположение диска, что приятно, когда ваш источник хранится в контроле версий. С другой стороны, если вы перемещаете файлы на диск, исправление ссылок Xcode является ручным и утомительным, но это можно сделать. Проще всего создать свою организацию с помощью программы get-go и создать файлы в каталоге, где они принадлежат.
Мое мнение
Хотя было бы неплохо иметь механизм пакета / пространства имен, не задерживайте дыхание, чтобы это произошло. Классовые конфликты на практике довольно редки и, как правило, очевидны, когда они происходят. Пространства имен - это действительно решение проблемы без проблем в Objective-C. (Кроме того, добавление пространств имен устраняет необходимость в обходных методах, таких как префиксы, но может привести к гораздо большей сложности при вызове метода и т. Д.)
Более тонкие и хитрые ошибки возникают из-за конфликтов методов, когда методы добавляются и / или переопределяются не только подклассами, но также являются категориями, которые могут вызывать неприятные ошибки, поскольку порядок загрузки категорий не определен (недетерминирован). Реализация категорий - один из самых острых краев Objective-C, и его следует пытаться, только если вы знаете, что вы делаете, особенно для стороннего кода, и особенно для классов каркаса Cocoa.