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

Question

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

Answer 1

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

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

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

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

Нейминг

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

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

Организация

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

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

Мое мнение

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

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

Answer 2

Они используют длинные имена ...

• Статья о стиле кодирования и наименовании в Какао / Objective-C
• Обсуждение, нуждается ли Obj-C в пространствах имен (удалено, архив здесь )

Answer 3

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

Answer 4

Неудобно, что цель c не имеет эквивалента пространства имен C #, c ++ и пакета java ....

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

Пройдите по следующему URL, чтобы узнать больше о соглашениях об именах, согласно совету Apple

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

Answer 5

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

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

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

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

Answer 6

Как насчет этого (внутри каталога)?

 #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];