Действительно ли конфликты пространств имен являются проблемой в Objective-C?

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

Цитата из приведенной выше ссылки:

Objective-C не имеет пространств имен, поэтому перед именами классов ставьте инициалы. Это позволяет избежать «коллизии пространств имен», когда два фрагмента кода имеют одно и то же имя, но делают разные вещи.

Полагаю, в этом есть смысл. Но, честно говоря, в контексте относительно небольшого приложения (скажем, игры для iPhone), действительно ли это проблема? Должен ли я действительно переименовать MyViewController в ZPViewController? Если нет, то в какой момент конфликты пространств имен действительно становятся проблемой?


person zpasternack    schedule 20.06.2009    source источник
comment
Objective-C не имеет пространств имен, поэтому перед именами классов ставьте инициалы. Ух, какой классный пластырь. Я бы хотел попасть в Objective-C, но отсутствие пространств имен абсолютно глупо.   -  person The Muffin Man    schedule 26.04.2012
comment
@Nick С тех пор, как я написал это почти два года назад, я опубликовал пять приложений в магазине приложений и никогда не сталкивался с этой проблемой. Отсутствие пространств имен действительно кажется не проблемой, по крайней мере, для меня это не было (ответы ниже в значительной степени подтверждают это).   -  person zpasternack    schedule 06.05.2012
comment
Итак, допустим, у вас есть класс, который конфликтует с другим, есть ли способ выбрать, какой из них вы хотите, или вы вынуждены вернуться и переименовать?   -  person The Muffin Man    schedule 07.05.2012
comment
@Nick Полагаю, вам придется переименовать его, но опять же, у меня никогда не было этой проблемы. Кроме того, Xcode позволяет довольно легко переименовывать классы, просто щелкните правой кнопкой мыши имя класса и выберите Refactor- ›Rename.   -  person zpasternack    schedule 08.05.2012
comment
Если вы планируете предоставить собственный фреймворк для распространения, велика вероятность того, что вы столкнетесь с конфликтом имен. Если вы просто собираетесь использовать какие-то другие фреймворки, очевидно, у вас не будет конфликта имен, потому что у вас есть выбор изменить имя класса. Добавление инициалов на самом деле не является надежным решением, но это лучшее, что у нас есть на данный момент.   -  person Deepak G M    schedule 05.02.2013


Ответы (4)


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

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

person Greg Hewgill    schedule 20.06.2009
comment
Подобные двухбуквенные префиксы зарезервированы Apple для использования в классах фреймворка. - person Amin Negm-Awad; 18.05.2015

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

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

Например, используйте переменные camelCase в Java, но переменные CamelCase в C #, имена, разделенные дефисом, в C и т. Д.

Это облегчит вам обучение в долгосрочной перспективе.

person uncleO    schedule 20.06.2009

Я читал (но не проверял), что у Apple есть частные классы в своих фреймворках, которые не включают никаких префиксов в именах. Поэтому, если имена классов вашего приложения не имеют префиксов, вы рискуете столкнуться с ними.

person Kristopher Johnson    schedule 20.11.2013

Я работал с репозиториями, в которых классы не имели префикса. (Или только некоторые классы имели префиксы.)

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

Имейте в виду, что код будет прочитан гораздо больше, чем написан.

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

person funroll    schedule 27.12.2013