Почему один модуль имеет доступ к другому, если у первого нет второго в «Связанных фреймворках и библиотеках»?

Question

У меня есть два проекта Cocoa Touch Framework main и sub в одной рабочей области. main использует протоколы и классы из sub . main компилируется. Но он не имеет ссылки на sub в «Связанных фреймворках и библиотеках» и «Фазах сборки».

Почему он компилируется? Что касается меня, это не правильно. Я хочу контролировать зависимости между модулями. Как закрыть доступ к модулю sub в main ?

---

Примечание 1 (31.10.19)

Та же история с двумя статическими библиотеками Cocoa Touch, но в этом случае у меня нет возможности добавлять что-либо в «Связанные фреймворки и библиотеки», только в «Фазы сборки». Кроме того, при попытке импортировать статическую библиотеку Cocoa Touch в Cocoa Touch Framework и наоборот - ничего не изменилось.

---

Примечание 2 (05.11.19)

Текущая заметка - это реакция на ответы. Потому что для меня, похоже, я не описал проблему четко. И заметка пытается это исправить.

Все мои фреймворки и библиотеки во время исследования были в едином рабочем пространстве. Раньше я думал, что это рабочее пространство - это документ XCode, который группирует проекты и другие документы, чтобы разработчик мог работать над ними вместе. Как я вижу сейчас, рабочая область - это нечто большее, чем улучшение UX. Это создает эффекты на уровне кода. Решает ли моя проблема удаление проектов из рабочей области? И если да, то как это сделать? «Улучшение UX для разработчика» и «Побочный эффект управления зависимостями» неразрывно сочетаются в рабочем пространстве? Могу ли я использовать только часть UX Улучшение для разработчика? Если да, то как?

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

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

Answer 1

Секция Linked Frameworks and Libraries просто говорит Xcode связать модуль sub с модулем main после его сборки. Таким образом, во время выполнения, когда что-то в main вызывает import Sub, модуль sub фактически может быть найден и импортирован.

Возможно, вы захотите проверить в Dependencies разделе Build Phases. Если там присутствует sub, это говорит системе сборки, что при сборке main вы также хотите перестроить sub, если она вообще была изменена.

Однако я не думаю, что даже это сделает так, что main не сможет import Sub. Причина в том, что обе платформы находятся в одной рабочей области. Даже без настройки Dependencies или Link Frameworks, если вы откроете рабочую область, создадите sub, а затем попытаетесь import Sub внутри main - это будет работать.

Это потому, что рабочие пространства Xcode эффективно создаютобщее местоположение для их артефактов сборки. Пока фреймворки находятся в одной рабочей области, можно будет импортировать одну в другую. Хотя вы получите очень странное поведение, если будете делать это без настройки Dependencies или Link Frameworks, поэтому я постараюсь избежать этого.

Если вы пытаетесь найти все import Subзвонки, я бы порекомендовал сделать поиск по всему проекту.

Если вы хотите сделать некоторые части инфраструктуры sub недоступными для других платформ, вам следует использовать модификаторы контроля доступа Swift. Все, что public или open будет видно другим фреймворкам.

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