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

We use cookies. Read the Privacy and Cookie Policy

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

Даже после множества примеров применения соответствующих подходов вам может быть не ясно, когда же следует использовать отображение, динамическую загрузку, динамическое связывание и пользовательские атрибуты в программах. Строго говоря, эти вопросы (которые увлекательны сами по себе) можно отнести, скорее, к теоретической стороне программирования (что можно считать как достоинством, так и недостатком, в зависимости от точки зрения). Чтобы спроецировать эти вопросы на реальность, нам нужен реальный пример. Представьте себе на минуту, что вы работаете в команде программистов, созданной для разработки приложения, удовлетворяющего следующему требованию:

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

Но что именно подразумевается под требованием допускать расширение? Рассмотрим Visual Studio 2005. При разработке этого приложения в нем были предусмотрены различные "гнезда" для подключения к IDE пользовательских модулей других производителей программного обеспечения. Ясно, что команда разработчиков Visual Studio 2005 не имела при этом возможности установить ссылки на внешние компоновочные блоки .NET, которые эта команда не разрабатывала (так что о статическом связывании не могло быть и речи). Поэтому закономерен вопрос: как именно это приложение смогло предложить необходимые гнезда подключения?

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

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

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

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