Какой паттерн использовать?

Question

[edwardoid]

Задача такая:

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

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

Структура приложения такова:



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


Пишу на C++/Qt

Answer 1

[Владимир Голованов]

Необходимо конретизировать требования, а именно:

• Плагины пишутся для внутреннего использования, или могут быть сторонные плагины?
• Верно ли предположение, что все вызовы плагинами друг друга происходят в пределах одного и того же потока?

Я бы реализовывал это следующим образом.

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

Возврат результата, возможно, имеет смысл делать не структурой, а обратным вызовом (если в пределах одного потока). Это даст возможность реализовать поэтапную обработку (если параметром служит какой-либо поток данных).

Comments

[Владимир Голованов]

Кстати, Вам имеет смысл глянуть в сторону интерфейсов, например, по аналогии с COM-объектами (т.е. один плагин может иметь несколько интерфейсов).
Это в случае, если в Вашем случае приемлемо создавать разные интерфейсы для плагинов.

[edwardoid]

Видимо я не совсем точно описал ситуацию. Все плагины по очереди обрабатывают какие-то данные. Для всех плагинов структура этих данных одинакова, одна некоторым плагинам нужна частичная функциональность других, какие-то статические их(вторых) методы, скажем.
Плагины грузит мененджер плагинов, который не что иное как QPluginLoader и QMap< QString, CustomPlugin* >.
Все плагины работают в одном потоке.

[Владимир Голованов]

Поэтапную обработку одних и тех же данных очень хорошо делать декораторами.

[Владимир Голованов]

«Декоратор» позволит написать несколько маленьких атомарных обработчиков, а потом при вкладывании их друг в друга можно получить любую последовательность обработки. Хороший пример — обработка stream'ов.
P.S. Я программирую на Java, поэтому привести пример на C++ затрудняюсь. Но помнится, что stream'ы там тоже сделаны декораторами.

Answer 2

[Алексей Шеин]

Может быть вам поможет «Команда» и «Цепочка ответственности».

Comments

[edwardoid]

я думал о цепочке ответственности, мне кажется это наиболее подходящим, потому и спросил…

[Алексей Шеин]

У вас все же немного другая ситуация как мне кажется. В цепочке ответственности плагины не используют друг друга, а просто определяют могут ли они обработать запрос или нет, и в случае неудачи передают команду дальше по цепочке.
Могу посоветовать следующее:
— определите четкий интерфейс для плагинов, так чтобы их легко можно было реализовать расширив небольшой абстрактный класс (чистых интерфейсов в с++ вроде нет, насколько я помню)
— сделайте обертку из класса над возвращаемой структурой и поместите туда часто используемые методы ее обработки, это облегчит остальные плагины и, возможно, позволит отследить путь передачи команды между плагинами.
Ну и пишите модульные тесты, они как ничто другое положительно влияют на архитектуру программы :)

[Владимир Голованов]

См. коммент выше, при одинаковых данных точно нужен декоратор. Причем это не отменяет ваших советов, а дополняет.

Answer 3

[zizop]

Думается мне, что в таком случае надо использовать паттерн «Стратегия».

Стратегия, Strategy — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путем определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.

Comments

[Владимир Голованов]

Думаю, в данном случае не тот вариант. Strategy предназначен для динамической подмены алгоритма. Здесь же, я так понимаю, плагины более-менее статичные, и хочется молучить минимальную связанность между ними. В этом случае подойдет отвязка через интерфейсы + получение экземпляров через фабрику.