Можно ли разделить частную среду Swift между подмодулями CocoaPod?

Question

Я создаю SDK с модулем «Core» и несколькими дополнительными подмодулями «а-ля-карт». Я хотел бы доставить его с помощью Cocoapods и их субмодульных функций во многом так же, как iOS Firebase SDK:

• SDK
  • Submodule-A
  • Submodule-B

Так что разработчики могут pod 'SDK' получить все подмодули или pod 'SDK/Submodule-A' и просто получить основной SDK + любые выбранные подмодули. Подобно тому, как вы можете получить Firebase/Auth или Firebase/Database или получить все это всего лишь с помощью Firebase. Однако, в отличие от Firebase, я хотел бы сохранить конфиденциальность исходного кода (упаковывая vendored-frameworks), а также, в отличие от Firebase, код - Swift.

Проблема, с которой я столкнулся, заключается в том, что существует некоторое общее «ядро» элементы и классы, API которых я хотел бы сохранить в секрете от тех, кто импортирует SDK (код внутренней общей сети и т. д. c), но может совместно использовать один экземпляр среди любых существующих субмодулей, и я хотел бы, чтобы этот код работал в SDK «Ядро», чтобы к нему могли обращаться и делиться любые подмодули.

Раньше это было возможно в Objective C путем «взлома» использования частных категорий, но Swift строже.

Возможно ли разделить частную среду Swift между подмодулями CocoaPod?

Answer 1

Я не могу подтвердить, что это дословный ответ (не фанат CocoaPods, поэтому мне немного не хватает всех его возможностей), но я вполне уверен в том, что я должен поделиться.

Это звучит очень похоже на концепцию желания иметь возможность тестировать частные свойства и функции в Swift. Простой ответ на это, что вы не можете. То, что является частным для модуля Swift, является строго частным, и поскольку модульные тесты являются отдельным модулем, они не могут получить доступ к чему-то менее разрешающему, чем символы, помеченные как public, без импорта тестируемого модуля с атрибутом @testable (который обеспечивает только доступ к internal символы уровня на самом низком уровне.

Менее простой ответ на этот вопрос заключается в том, что вы затем протестируете эти приватные методы с помощью символов, к которым вы МОЖЕТЕ получить доступ (или пожертвуете приватным уровнем ради тестирования), и подтверждая, что доступные символы работают правильно, вы можете смело предполагать, что частные символы поддерживают их адекватно.

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

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

...

Может быть, этот подход будет работать для вас (я не могу ни подтвердить, ни опровергнуть, если это будет наилучшей практикой, но я думаю, что это будет работать):

Создайте модуль с именем MyFramework-Private, в котором есть все, что вы хотите скрыть от пользователя, но со всеми общими методами и свойствами на уровне public. Импортируйте это в любой модуль, который, в конечном итоге, вы хотите видеть пользователем, но не включайте его в инструкции для разработчика. Это не остановит пользователя от доступа к этому модулю, но даст понять, что он не поддерживается и не рекомендуется. Таким образом, MyFramework-Database будет импортировать MyFramework-Private, но пользователь будет импортировать только MyFramework-Database и подвергаться воздействию только тех публикаций c (или открытых), которые имеются в части Database .