Здравствуйте, Bdud, Вы писали:

B>Доброго времени суток.
B>Возникла следующая задача и я не знаю, как её наиболее элегантно решить.
B>Постановка задачи. Сейчас я работаю с некоторым SDK (условно назовём его SDK A), который реализован ввиде com объектов. Возникла необходимость работать с SDK B, реализующим тот же самый функционал, что и SDK A, но выполнен он просто ввиде api функций. Выбор между использованием того или иного SDK выполняется в runtime'е, причём этот выбор довольно дорогостоящий т.е. определить его лучше всего один раз.
B>Возможные решения.
B>1. Можно реализовать wrapper над com классом и набором функций и передавать дополнительный параметр при инициализации, который определяет какой из SDK использовать (определить глобально). Минус данного подхода — много изменений в существующем коде.
B>2. Можно попробовать исползовать какой-нибудь агрегирующий объект, который будет хранить такую переменную, и уже через него будет предоставляться вызов того или иного метода или функции. Минус решения — тот же, что и у первого способа, плюс выглядит как-то монолитно.
B>Подскажите пожалуйста наиболее элегантный вариант решения данной проблемы.

Если я правильно понял то, что выше написано, то сначала по-любому надо привести оба SDK к одному программному интерфейсу, то есть написать wrapper с делегацией методов соответствующему SDK, интерфейс wrapper должен быть одинаковый. Далее можно создать фабрику, которая в зависимости от настроек при ее создании вернет ссылку на wrapper того или другого SDK, это будет прозрачно для приложения.
У меня была похожая но более сложная задача, обеспечить возможность тонкой настройки библиотеки, т.е. для каждого интерфейса обеспечить выбор конкретной реализации в runtime, я решил это через Inverse Of Control (IoC), советую почитать.