LINUX.ORG.RU

Кто знает как динамически загружать классы


0

0

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

Проект разбивается на две части: программа, которая пишется сейчас, и библиотека к ней, которая пишется когда-нибудь потом.
1. На этапе проектирования определяется некий интерфейс MyInterface
2. Пишется программа, знающая про MyInterface
3. В рамках библиотеки пишется класс MyClass, реализующий MyInterface, + фабрика объектов
4. Программа загружает библиотеку
5. Фабрика выдаёт программе объект
6. Программа использует известные ей методы MyInterface для получения указателей на методы класса MyClass, программе неизвестные
7. Программа передаёт методы в нужные места

Что мне в этом не нравится:
1. Методы, не определённые в MyInterface (т.е. не известные программе) должны иметь заранее определённый тип, т.е. кол-во и типы аргументов и возвращ. значение
2. Много бессмыссленного кода для выдачи указателей на методы и для фабрики объектов

Существуют ли другие способы сделать это?
Заранее спасибо.

Эсли используешь QT, то обрати внимание на сиситему плагинов, похоже это как раз то что тебе нужно, там даже достаточно развёрнутый пример с их использованием есть!

LestorN
()

По моему автор топика не очень хорошо понимает ООП.

Зачем получать у обьекта указатели на методы если можно передать указатель на сам обьект и преобразовать его к нужному типу и вызывать нужный метод.

RTTI помогает.

Аффтар учи матчасть. :)

imp ★★
()

> Начинаю работу над С++ проектом(Qt), в котором требуется использовать динамически загружаемые классы.
Сто против одного, что это требование надуманное и не имеет под собой никакого обоснования.
Ты бы лучше огласил реальную задачу.

gpg
()
Ответ на: комментарий от imp

Причём тут понимание ООП? Я же не курс ООП прохожу. Передо мной стоит задача, её нужно решить. Вариант "преобразовать его к нужному типу и вызывать нужный метод" проблему не решает, вариант Qt signal/slot решает.

philip
() автор топика
Ответ на: комментарий от philip

Какое отношение имеет "Qt signal/slot" к "динамической загрузке классов"?

gpg
()

Гошшподя, на какие извраты идет народ, лишь бы не использовать языки с нормальным ОО.

svu ★★★★★
()
Ответ на: комментарий от svu

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

gpg
()
Ответ на: комментарий от gpg

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

Но даже когда интерфейс известен, гораздо удобнее с ним оперировать через нормально реализованную рефлексию.

svu ★★★★★
()
Ответ на: комментарий от gpg

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

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

Можно было бы использовать универсальную сигнатуру метода типа int foo(int, void *), но это приведёт к
1) тому, что все методы будут "подходить" ко всем
2) путанице в голове библиотекописателей

Базара нет, что-то можно обойти или от чего-то отказаться, но раз уж
существуют средства реализации всего да ещё и одним тулкитом(Qt) - не вижу смысла это делать.

philip
() автор топика
Ответ на: комментарий от philip

> Моя задача состоит в том, чтобы обеспечить производство программы, состоящей из нескольких разных компонентов(библиотек),
> которые будут написаны в разное время разными людьми. При этом сборка программы воедино НЕ должно достигаться компиляцией,
> т.к. должно происходить без участия программиста.
Это описание подходит почти к любому проекту.
В чём специфика?

gpg
()
Ответ на: комментарий от gpg

Поконкретнее о чем? С чем именно не согласитесь про рефлексию? С тем, что это намного гибче, чем жестко вкомпилированные интерфейсы?

svu ★★★★★
()
Ответ на: комментарий от gpg

Специфика в том, что у системы нет какой-либо базовой функциональности - она лишь обеспечивает работу компонент-библиотек, такая моя задумка.

philip
() автор топика
Ответ на: комментарий от svu

Поконкретнее про "работу с неизвестными (любыми) классами" в "универсальном прокси из одной компонентной архитектуры в другую".

Не согласен с этим:
"Но даже когда интерфейс известен, гораздо удобнее с ним оперировать через нормально реализованную рефлексию."

gpg
()
Ответ на: комментарий от gpg

Это было лет 4-5 назад, поэтому помню очень смутно. Идея была в том, что понадобилось то ли из какой-то корбы в ejb транслировать, то ли наоборот (даже этого не помню точно) - существенно то, что заранее не было известно ничего об интерфейсах.

Почему не согласны с тем, что через рефлексию удобнее? Да, через жестко вкомпилированные интерфейсы проще, уменьшает вероятность ошибки - но вместе с тем не дает возможности "прощать" легкие несоответствия интерфейсов (например, если интерфейс поменялся между версиями, такое бывает в жизни).

svu ★★★★★
()
Ответ на: комментарий от svu

1. Всё равно не понимаю. Если речь идёт о маршалинге, то это работа по конвертированию бинарных данных из одного формата в другой.
Классы тут вообще не фигурируют. Если нет, то о чём?

2. А зачем их прощать? Заплатки имеют свойство рано или поздно всплывать и выходить боком. Приемлемое решение тут - QueryInterface.

gpg
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.