Objective-C эквивалент пакетов Java?

Что такое Objective-C эквивалент пакетов Java? Как вы группируете и организуете свои классы в Objective-C?

Ответы

Ответ 1

Вопрос 1: Objective-C эквивалент пакетов Java?

Objective-C не имеет эквивалента пакетам Java или пространствам имен С++. Частично это объясняется тем, что Objective-C изначально был очень тонким слоем времени поверх C, и добавил объекты на C с минимальной суматохой. К сожалению, для нас сейчас конфликты имен - это то, с чем нам приходится иметь дело при использовании Objective-C. Вы выигрываете, теряете некоторые...

Небольшое разъяснение (хотя это мало для утешения) состоит в том, что Objective-C на самом деле имеет два плоских пространства имен - один для классов и один для протоколов (например, интерфейсы Java). Это не решает конфликтов имен, но это означает, что вы можете иметь протокол и класс с тем же именем (например, <NSObject> и NSObject), где последний обычно принимает ( "реализует" ) первый. Эта функция может предотвратить распространение шаблона "Foo/FooImpl" на Java, но, к сожалению, это не помогает в конфликтах классов.

Вопрос 2: Как [имя] и организовать классы Objective-C?

Нейминг

Следующие правила являются субъективными, но они являются достойными рекомендациями для именования классов Objective-C.

  • Если ваш код не может быть запущен другим кодом (это не фреймворк, плагин и т.д., а приложение или инструмент конечного пользователя), вам нужно избегать конфликтов с кодом, с которым вы ссылаетесь. Часто это означает, что вы можете обойтись без префикса вообще, пока используемые вами фреймворки/плагины/пучки имеют собственные пространства имен.
  • Если вы разрабатываете "компонентный" код (например, фреймворк, плагин и т.д.), вы должны выбрать префикс (надеюсь, тот, который уникален) и документировать, как вы его используете, где-то видимым, чтобы другие знали, чтобы избежать потенциальных конфликтов. Например, CocoaDev wiki "registry" является де-факто открытым форумом для вызова "dibs" на префикс. Однако, если ваш код является чем-то вроде внутренней структуры компании, вы можете использовать префикс, который еще кто-то делает, если вы не используете что-либо с этим префиксом.

Организация

Организация исходных файлов на диске - это то, что многие разработчики Cocoa, к сожалению, замаскируют. Когда вы создаете новый файл в Xcode, по умолчанию используется каталог проекта, прямо у вашего файла проекта и т.д. Лично я добавляю источник приложения в source/, тестовый код (OCUnit и т.д.), в test/, все ресурсы (файлы NIB/XIB, Info.plist, изображения и т.д.) в ресурсах / и т.д. Если вы разрабатываете сложный проект, то также может быть хорошим решением для группировки исходного кода в иерархии каталогов на основе функциональности. В любом случае хорошо организованный каталог проектов облегчает поиск того, что вам нужно.

Xcode действительно не заботится о том, где находятся ваши файлы. Организация на боковой панели проекта полностью не зависит от расположения диска - это логическая (не физическая) группировка. Вы можете организовать, как вам нравится, на боковой панели, не затрагивая местоположение диска, что приятно, когда ваш источник хранится в контроле версий. С другой стороны, если вы перемещаете файлы на диск, исправление ссылок Xcode является ручным и утомительным, но это можно сделать. Проще всего создать свою организацию с помощью get-go и создать файлы в каталоге, где они принадлежат.

Мое мнение

Хотя было бы неплохо иметь механизм пакета/пространства имен, не задерживайте дыхание, чтобы это произошло. Конфликты классов на практике довольно редки на практике, и обычно они очевидны, когда они происходят. Пространства имен - действительно решение для не-проблемы в Objective-C. (Кроме того, добавление пространств имен устраняет необходимость в обходных методах, таких как префиксы, но может привести к гораздо большей сложности при вызове метода и т.д.)

Более тонкие и хитрые ошибки возникают из конфликтов методов, когда методы добавляются и/или переопределяются не только подклассами, но также являются категориями, что может вызвать неприятные ошибки, поскольку порядок загрузки категории undefined (недетерминированность). Внедрение категорий является одним из самых острых ребер Objective-C, и его следует пытаться, если вы знаете, что делаете, особенно для стороннего кода, и особенно для Cocoa классов инфраструктуры.

Ответ 4

К сожалению, объективный c не имеет никакого эквивалента пространству имен С#, С++ и пакета java....

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

Пройдите следующий URL-адрес, чтобы узнать больше об именовании, как сообщается apple

http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html

Ответ 5

Как насчет чего-то подобного (внутри каталога)?

 #define PruebaPaquete ar_com_oxenstudio_paq1_PruebaPaquete
@interface ar_com_oxenstudio_paq1_PruebaPaquete : NSObject {

и импортировать его следующим образом:

 #import "ar/com/oxenstudio/paq1/PruebaPaquete.h"
 PruebaPaquete *p = [[PruebaPaquete alloc] init];

и при столкновении имен:

 #import "ar/com/oxenstudio/paq1/PruebaPaquete.h"
 #import "ar/com/oxenstudio/paq2/PruebaPaquete.h"


ar_com_oxenstudio_paq1_PruebaPaquete *p = [[ar_com_oxenstudio_paq1_PruebaPaquete alloc] init];
ar_com_oxenstudio_paq2_PruebaPaquete *p2 = [[ar_com_oxenstudio_paq2_PruebaPaquete alloc] init];

Ответ 6

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

Когда я создаю класс, я нахожу, что довольно часто я хочу, чтобы какой-то конкретный класс вызывал его методы, b/c они работают вместе для достижения задачи, но я не хочу, чтобы все остальные не связанные классы для вызова этих методов. Именно здесь доступно управление доступом к пакету java, поэтому я могу сгруппировать связанные классы в пакет и настроить эти методы для контроля доступа к частному доступу. Но в объекте c нет способа сделать это.

Без контроля доступа к частному доступу я считаю, что очень сложно избежать написания кода таким образом [[[[[a m1] m2] m3] m4] m5] or [a.b.c.d m1].

Обновление: Xcode 4.4 представил "Заголовок расширения класса Objective-C", на мой взгляд, который каким-то образом предоставляет "контроль доступа к частному доступу", поэтому, если вы включаете заголовок расширения, вы можете вызвать мой "пакет" частные "методы; если вы включаете только мой общий заголовок, вы можете вызвать только мой публичный API.