Теория создания подключаемых модулей (PlugIn's)

[STRELOK-2007]

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

Где то в 2008 году делал программу одну для сталкера, и там использовались подключаемые модули. Делал просто, по книге Михаила Фленова - "Делфи глазами хакера". Там использовалась банальная и простая, но довольно тупиковая идея - создается класс, который передается в модуль. Модуль же знает о нем, с помощью абстрактного класса который находиться в SDK. Программа сама оказалась слишком избыточной и не нужной для сталкера, и я как бы заморозил - да и можно сказать бросил - разработку.

Возвращаясь к теме, скажу, что на данный момент самым идеальным можно назвать способ с использованием интерфейсов... Так как на сколько я знаю все существующие компилируемые языки, поддерживают создание библиотек dll и интерфейсы - то что надо. На делфи я программирую лет 5-6, т.е. чувствую себя хорошо, а вот другие языки, даже общее представление не полное...

1) Первым что хочется спросить, какие типы данных лучше использовать для параметров функций и для возвращаемых результатов? - скажем в данный момент в альфа версии менеджера использую такие типы: record, WideString, Real. Какие еще стандартные типы можно использовать? Можно ли скажем использовать процедуры в качестве типов данных? (TSomeProc = procedure (x: Integer) Также слышал, что можно использовать Variant в качестве типа данных - так ли это?

2) Ну как известно, чтобы обеспечить интерфейс работой, то нужна реализация. С этим проблем нет... Но есть такой вопрос: вроде бы можно сделать несколько скажем приватных классов, которые реализовали интерфейсы. И потом делегировать их интерфейс основному классу... Даже вроде есть ключевое слово, которое ставится после объявления класса - но делфи 2010 чтото никак не хочет принимать его, в чем может быть проблема? И можно ли вообще так? - может быть я понял не правильно?

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

4) Вот менеджер плагинов, давайте теперь поговорим о нем... Это некий класс, который содержит в себе какой то список модулей и обеспечивающий их работу... По вашему мнению, какой функционал он должен будет обеспечивать?
Я вот как сделал (пока): При инициализации менеджера, задается путь к папке с модулями. Расширение модуля, имя процедуры - точки входа - сказыватсь в СДК. Также в самом начале указывается базовый интерфейс API программы. Так вот, менеджер ищет нужные файлы, загружат библиотеку, ищет процедуру, если есть вызывает ее и получает интерфейс, если в нем реализован интерфейс плагина, то добавляет его в список, при этом элементом списка является тоже класс, который реализует интерфейс с помощью которого модуль узнает о себе информацию, так вот при добавлении модуля в список ему передаются интерфейсы его информационного класса и класса апи. Это все реализовано в интерфейсе модуля, также там реализованы 4 функции, вызывающиеся в соответсвии с их названиями (Initialize, Load, Eject, Finalize).

Пока что до конца не додумал, но на правильном ли я пути? Или что то уже сейчас не правильно спроектировал?
4) Теперь очень серьезеный вопрос, что нужно как бы предоставить модулю, чтобы он смог создать каким то образом создать свой элемент управления или форму скажем? Ведь TApplication нельзя передавать? Какие есть способы?

5) Каким образом можно реализовать вот что: если модуль что то куда то добавляет, или создает какие либо классы - то про выгрузке автоматически это все дело освободить?

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

[STRELOK-2007]

Ну что? Напишите хоть что нибудь? А то обидно, ни на одну мою тему нет ответа