Чем Framework и Stati c Library отличаются для инверсии управления в iOS?

Question

В одном из ответов на вопрос iOS Framework против Static Library, yoAlex5 в кавычках,

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

Framework воплощает в себе какой-то абстрактный дизайн с более встроенным поведением. Чтобы использовать его, необходимо вставить свое поведение в различные места в структуре либо путем создания подклассов, либо путем подключения ваших собственных классов. Код фреймворка затем вызывает ваш код в этих точках. Основной элемент управления программы перевернут, отодвинут от вас в рамки. (инверсия управления)

Можно ли привести любой пример для iOS с минимальным фрагментом кода, где я могу понять, как Static Library не может поддерживать инверсию управления, когда Framework может?

Answer 1

В принятом ответе на заданный вами вопрос упоминается следующее:

Следовательно, на iOS ваш единственный вариант - в основном использовать данные c библиотека или структура stati c (основное отличие состоит в том, что платформа stati c чаще всего распространяется как скомпилированный файл .a, тогда как библиотека stati c может быть просто включена как подпроект - вы можете видеть весь код, который компилируется первым, и его результирующий файл .a используется проектом в качестве зависимости).

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

Однако , даже если библиотека может предоставить все, что может сделать фреймворк, следует окончательно ограничить определенные функциональные возможности фреймворками. Wiki говорит :

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

• расширяемость: пользователь может расширять платформу - обычно путем выборочного переопределения - или программисты могут добавлять специализированный пользовательский код, чтобы предоставить конкретную информацию. c функциональность.
• немодифицируемый код фреймворка: код фреймворка, как правило, не должен изменяться при принятии пользовательских расширений. Другими словами, пользователи могут расширять инфраструктуру, но не могут изменять ее код.