Стоит задача разработать плагинную архитектуру для некоторой универсальной системы, которая состоит из ядра и множества подключаемых модулей (плагинов). Подключаемые модули могут разрабатываться после ввода системы в эксплуатацию. 
Немного о ядре:
Ядро построено по MVC схеме и в большей степени на абстракциях. Есть  активная  модель - одиночка (Singleton), которая занимается только подпиской и отпиской представлений и их уведомлением, а также содержит список объектов (экземпляры класса MyObject ). Каждый такой объект может содержать множество абсолютно любых данных о себе.   Контроллер управляет доступом к объектам модели и редактирует модель. Также в ядре определенно несколько видов представлений модели. Представление проверяет каждый объект на возможность его отображения (например, если объект реализует интерфейс IDrawable то соответствующее представление его отображает). Имеется менеджер плагинов, который отвечает за загрузку, выгрузку и проверку плагинов на валидность. 

Взаимодействие ядра с плагинами осуществляется через определенный интерфейс IPlugin, известный как ядру так и плагинам. В этом интерфейсе определен лишь один метод, который получает в качестве аргумента ссылку на контроллер. Таким образом плагин, реализовав этот интерфейс получает доступ к модели через контроллер. 


Вся основная функциональность должна быть реализована в плагинах. Плагины получают доступ к модели, наполняя её своими данными и функциональностью. Данные и функциональность модели определяются только в объектах модели и нигде больше. Т.е. каждый плагин создает своего наследника от класса MyObject,наполняет его своими специфическими данными и функциями и добавляет в модель. Для управления и отображения  объектами с новой функциональностью в плагине могут быть созданы собственные контроллер и представления, путем расширения их kernel-предков. 

Разработчикам плагинов поставляется PluginAPI, в который кроме интерфейса IPlugin включена спецификация ядра.

 
При проектировании такой архитектуры возникает несколько вопросов:
Как  организовать взаимодействие между плагинами?  т.е. как при написании сторонним разработчиком нового плагина воспользоваться функциональностью, заложенной в другом уже используемом в системе плагине, не имея доступа к спецификации этого плагина? т.е. в режиме выполнения основного приложения новый плагин сможет получить от ядра модель с объектами, содержащую новую информацию но понять что это за новая информация не сможет так как не обладает её описанием.  В связи с этим возникает вопрос как вообще формировать PluginAPI для разработчиков плагинов?   


Чувствую что наворотил что то ужасное... Подскажите как правильно всё спроектировать под такой специфический MVC.

Это сообщение отредактировал(а) Vitaly333 - 3.3.2010, 02:16

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

Т.е мне кажется, что взаимодействовать между собой могут только плагин-объект, и объект-объект, но не плагин-плагин. Потому что если плагин создал объект, а затем удалился, то объект в модели останется, и с ним надо будет как-то работать, поэтому я и предлагаю описать базовые методы классах от TMyObject о которых будут знать все - ядро, плагины и другие объекты.

ЗЫ: Плагины после загрузки становятся частью контроллера?

Тогда функциональность плагинов будет сильно ограничена. И какие методы в в эти абстрактные классы включать сложно сказать...
Я хочу сделать примерно так как это сделано в Eclipse. Там каждый плагин сам в себе определяет несколько точек расширения - т.е. несколько интерфейсов и/или классов из своей логики которые смогут расширить другие плагины. Эти классы прописываются в ядре и от туда их можно как то выгрузить - т.е. как то предоставить в виде SDK для разработчиков плагинов(пока непонятно как).  Разработчик плагина смотрит в среде, к которому подключено ядро с загруженными плагинами, список точек расширения и выбирает ему нужные. После этого среда генерит ему SDK с нужными ему классами и интерфейсами. Далее он подключает этот SDK к своему проекту и создает там свой плагин. 
Также я хочу ввести кроме точек расширения , точки использования - т.е. конкретные реализации классов, которые могут и/или должны быть использованы в других плагинах (например, в одном плагине определен класс для работы с матрицами Matrix и несколько интерфейсов которые могут быть расширены в других плагинах. И эти интерфейсы имеют зависимость от класса Matrix. Тогда чтобы расширить эти интерфейсы в других плагинах нужно обязательно знать что такое тип данных Matrix, а значит класс Matrix тоже должен быть включен в SDK).
Таким образом в плагине определяются:
- точки расширения;
- точки использования;
- расширения точек других плагинов.

Как  вам такой подход? Насколько сложно это сделать?

Это сообщение отредактировал(а) Vitaly333 - 9.3.2010, 14:15

Мне сложно говорить об абстрактном предмете. Можешь примерно описать что программа должна моделировать и какие к ней требования?

OSGi смотрел?

Типа второй эклипс хочешь написать?

Vitaly333, присоединяюсь к предыдущим ораторам: объясните, для чего система предназначена и какие функции она будет выполнять.

Проектирование начинается с отображения функциональности на архитектуру: т.е. нам нужно понимать, какие функции будут общими для всех, тогда их скорее всего нужно будет включить в ядро, какие специфическими - их будут реализовывать отдельными модулями, какие будут тесно связан друг с другом, какие независимы.

Только после этого можно уточнять детали, в противном случае сопровождение готового продукта сильно усложнится.

А это для чего и на чём? Для явы/дотнета/питона существует массма отличных палгин-фреймворков. Или просто интересно написать?