Почему обесцвечиваются зонтичные рамки?

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

Apple делает это все время, используя концепцию "Umbrella Frameworks", но есть эта тема в документах:

Не создавать рамки зонтика

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

Почему этот подход не рекомендуется? Что делает его хорошим решением для проблемы Apple взаимозависимых фреймворков, но не для моего?

Ответ 1

Рамки Umbrella имеют смысл только в том случае, если вы являетесь единственным дистрибьютором всех задействованных фреймворков, и вы будете собирать все фреймы вместе как единый пакет с версией, который будет обновляться вместе. Если это ваша ситуация, то это прекрасно, но это очень необычная ситуация. В мире развития Cocoa это необычно для всех, кроме Apple, в этой ситуации.

В первую очередь, зонтичные рамки имеют смысл только в том случае, если вы являетесь единственным дистрибьютором данных фреймворков. Например, скажите, что вы хотели включить libcurl как часть вашей зонтичной структуры. Теперь некоторые другие упаковщики также хотят включить libcurl как часть его зонтичной структуры. Теперь мы столкнулись с конфликтом времени, который может привести к ошибкам или ошибкам связи, undefined поведение во время выполнения. Я сам преследовал их. Они очень неприятны. Единственный способ избежать этого - предоставить только одну версию каждой среды/библиотеки. Зонтичные рамки поощряют противоположное.

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

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

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

Большая часть моего обсуждения здесь относится к OS X. В iOS это не проблема для сторонних разработчиков. Статические библиотеки никогда не должны связывать другие статические библиотеки из-за конфликтов, которые, безусловно, будут иметь место.

В теории большинство вопросов, которые я обсуждал здесь, принципиально технические ограничения компоновщика. У компоновщика нет хорошего способа управлять несколькими версиями библиотек, и поэтому столкновение является серьезной проблемой. Сборки .NET стараются обеспечить большую гибкость в этом отношении. Я недостаточно знаком с разработкой .NET, чтобы сказать, было ли это успешным или нет. Мой опыт работы с крупными многокомпонентными системами заключается в том, что для большинства проблем лучше всего использовать более простые и менее гибкие решения. (Но тогда трава всегда зеленее....)

Ответ 2

Одна из проблем заключается в том, что версия рамки B теперь привязана к версии рамки A. Это может быть то, что вы хотите в некоторых случаях, а не для других. Если среда B, вероятно, будет использоваться независимо приложением, которое также хочет использовать инфраструктуру A, приложение может оказаться в ситуации, когда версия B, включенная в A, не является той версией, которая ему нужна или хочет.

Является ли среда B структурой, которую приложение может использовать независимо от A? Если это так, вы можете столкнуться с этим сценарием. Если B - это фреймворк, который недоступен вне A, вы не должны запускать этот сценарий.

Ответ 3

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