Рекомендации по именованию API

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

Необходимо попытаться выбрать имена, ясно связывающие каждый символ с платформой. Например, рассмотрите добавление короткого префикса ко всем внешним именам символа. Префиксы помогают дифференцировать символы в Вашей платформе от тех в других платформах и библиотеках. Они также проясняют другим разработчикам, какая платформа используется. Типичные префиксы включают эти первые две буквы или акроним Вашего имени платформы. Например, функции в Базовой Графической платформе используют префиксный «CG».

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

Для подробных инструкций по соглашениям о присвоении имен Какао см. Инструкции по Кодированию для Какао.

Влияние производительности платформ

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

Когда их код совместно используется многократными приложениями, платформы являются самыми эффективными. При разработке комплекта приложений можно создать пользовательскую платформу для хранения общего кода, к которому получают доступ все приложения в комплекте. Точно так же можно хотеть создать частную платформу внутренне для выделения универсального, повторно используемого кода от специализированного кода. Несмотря на то, что можно встроить эту платформу в каждое приложение, Вы создаете, Вы упрощаете свое обслуживание повторно используемого кода.

Что включать в Вашу платформу

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

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

Используя C++ в коде платформы

Существуют проблемы, свойственные с экспортом интерфейсов класса C++ от динамических совместно используемых библиотек. Этими проблемами является результат отсутствия стандартизированных соглашений о вызовах для расширений, дифференцирующих язык C++ от C.

Для устранения соединения проблем между библиотеками, созданными с различными компиляторами, поставщики компилятора согласились поддерживать стандартизированные соглашения о вызовах набора для языка C. Эти стандарты потребовали, чтобы поставщики генерировали код C непротиворечивым способом, гарантировавшим, что код от одной библиотеки мог вызвать код от другой библиотеки. В то время как такой стандарт был предложен для расширений языка C++, он должен все же быть завершен. В результате нет никакой гарантии, что вызовы между двумя различными библиотеками C++ работали бы.

Если Вы полны решимости относительно использования кода C++ в Ваших платформах, лучший способ избежать, чтобы проблемы несовместимости обернули интерфейс для Ваших классов C++ с функциями ANSI C. При помощи C++ для Вашей реализации и ANSI C для Вашего интерфейса, можно продолжать разрабатывать на предпочтительном языке при обеспечении совместимого интерфейса для клиентов для вызова.

Если необходимо экспортировать интерфейсы класса от платформы, Apple рекомендует использовать Objective C вместо C++ для определения классов. Язык Objective C действительно имеет стандартизированный набор соглашений о вызовах, позволяющих Вам представить интерфейсы класса от своих платформ.

Для получения дополнительной информации и руководства об использовании C++ в совместно используемых библиотеках, см. Руководство по программированию Среды выполнения C++.

Не создавайте платформы зонтика

В то время как возможно создать платформы зонтика с помощью XCode, делание так является ненужным для большинства разработчиков и не рекомендуется. Apple использует платформы зонтика для маскирования некоторых взаимозависимостей между библиотеками в операционной системе. В почти всех случаях необходимо быть в состоянии включать код в единственный, стандартный пакет платформы. Также, если бы Ваш код был достаточно модульным, то Вы могли бы создать многократные платформы, но в этом случае, зависимости между модулями были бы минимальны или не существовали бы и не должны гарантировать создание зонтика для них.

Где установить Вашу платформу

OS X ищет общедоступные платформы в нескольких закрепленных расположениях в системе. При создании платформы для других разработчиков для использования, необходимо поместить ее в одно из этих расположений. При создании частной платформы можно или встроить ее в приложении или поместить ее в пользовательское расположение. В любом случае необходимо выполнить некоторую дополнительную работу для загрузки кода платформы и ресурсов.

Для получения дополнительной информации на том, где установить платформы, посмотрите Установку Вашей Платформы.