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

Здравствуйте, 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), советую почитать.

>>я решил это через Inverse Of Control (IoC), советую почитать.
Врядли Иок прокатит. ті то наверняка спринг имеешь а у парня КОм обьекты..запартится.
Но вообщето в гофу решение это задачи — паттерн Бридж(мост).

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

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

Точно такая же проблема с решением описана в книге "Шаблоны проектирования", Алан Шаллоуей, Джеймс Р. Тротт. Используется не один конкретный шаблон, а набор взаимодействующих шаблонов.

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

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

Хотя задача была решена без использования Inverse Of Control, хотелось бы для повышения уровня образованности почитать про данный метод. Честно искал, но не обнаружил ничего подходящего

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

B> Хотя задача была решена без использования Inverse Of Control, хотелось бы для повышения уровня образованности почитать про данный метод. Честно искал, но не обнаружил ничего подходящего

Inversion of Control
У Фаулера этот паттерн называется Dependency Injection

Ну и здесь имеет смысл посмотреть: http://en.wikipedia.org/wiki/Dependency_injection