Як би можна було створити підключається програмне забезпечення?

Якщо у вас є якась програма та ви хочете, щоб ваші користувачі могли писати плагіни для неї, як слід розробити програму?

Що ви повинні врахувати, які дизайнерські шаблони для цього тощо?

design plugins extensibility

— user9238
джерело

Приходять такі моделі, як спостерігач, посередник, командна реклама, ланцюжок відповідальності

— Mchl

@Mchl: Будь ласка, опублікуйте свою відповідь як відповідь, а не як коментар.

— S.Lott

Погляньте на Меф та інформацію про MSDN

— Luc Bos

Я вважаю, що це недостатньо детально для цього

— Mchl

@Mchl: "недостатньо детально"? Тоді навіщо взагалі коментувати? Це однозначно відповідь. Будь ласка, опублікуйте відповіді як відповіді.

— S.Lott

Відповіді:

Це якось залежить від вашої платформи, але деякі загальні речі, які слід пам’ятати

Версія. Що станеться, якщо ви оновите свою програму, чи старі плагіни застаріли (проблема firefox)

Ізоляція Чи можуть плагіни робити все, що хочуть? Ви їм завжди довіряєте? Або вам потрібно запустити їх у якусь пісочну скриньку та запитувати дозволи.

Оновлення Як обробляти оновлення плагінів?

Безпека Як убезпечити автора плагіна, запобігти підробці або підманювати користувача встановити шкідливий код. Зазвичай вирішується якимось підписом коду

Серіалізація Часто, коли ви використовуєте якусь ізоляцію, вам потрібно серіалізувати інформацію між різними потоками чи процесами. Як це зробити найбільш ефективно?

Розширюваність Які аспекти потрібно розширити? Як ви максимізуєте потенціал плагінів без API, який стає непростим.

Якщо ви орієнтуєтесь на сторонніх розробників для плагінів, я б сказав, що найголовніше (з мого досвіду) - це бачити api та класи плагінів як абсолютно інші від решти програми, і зробити це так само просто для розробки якомога. Архітектурі з головного додатка дуже просто "кровоточити" в плагіни, щоб автори плагінів повинні навчитися набагато більше, ніж їм доводиться. Полегшіть їх, подумайте, який саме інтерфейс та досвід ви хочете отримати як автор плагіна.

Ще одна вдала думка - не думати на кшталт "Плагін зробить усі ці речі (в коді), а, скоріше," плагіну потрібно надати цю інформацію ". Таким чином додаток може споживати необхідну інформацію та робити фактичну обробку, яка спростить. плагін.

Крім того, загалом, коли ви можете використовувати описовий підхід (метадані, як xml), а не код, ви маєте велику перевагу, оскільки метадані легше транспортувати, версію, розгортання, безпеку і їх можна легше налаштувати сторонніми сторонами

— Хомде
джерело

+1 Це питання не відповідає безпосередньо на питання, але це важливі питання, про які слід пам’ятати

— Адріано Карнейро

Я вважаю, що ці питання висвітлюються ще до того, як хтось почне розробляти власне механізм розширення

— Gus

Я це написав статтю Code Project про використання MEF для розширення в .NET. Це гарне вступ.

Існують і інші рамки розширення для .NET, такі як архітектура надбудови SharpDevelop , Mono.Addins та System.AddIn .

Для Java існує архітектура плагінів Eclipse .

Загальна закономірність така:

Ви визначаєте договір (як правило, інтерфейс) між хостом і розширенням
Вам потрібен механізм виявлення, який вимикається і шукає встановлені розширення
Потрібно вміти динамічно завантажувати розширення та давати їм знати хост

На практиці вона багато в чому поділяється введенням залежності та стратегічною схемою.

— Скотт Вітлок
джерело

+1 MEF і System.AddIn - це і корисні речі. Навіть якщо ви не закінчите їх використовувати, вони обидва показують хороші концепції.

— RationalGeek

@jkohlhepp - Я погоджуюсь, і я б запропонував глибоко зануритися в архітектуру SharpDevelop, оскільки про неї багато написано, вона є відкритим кодом (так це MEF, btw), і він добре розроблений.

— Скотт Вітлок

Вам просто потрібно надати інтерфейс для плагінів.

Він повинен містити принаймні Activate-Methode (точку входу), але вам також потрібні такі речі, як Initialize тощо.

Повинна бути можливість спілкуватися з хост-програмою у вигляді реєстру, наприклад, для реєстрації елементів меню. Тому реєстри речей, які можна змінювати / розширювати для плагінів, повинні бути передбачені.

Крім того, має бути доступне сховище для даних та об’єктів хост-програми, тому плагіни можуть викликати його підпрограми. Це можна легко зробити, використовуючи контейнер DI типу, як Unity, і дозволити плагінам доступ до нього, щоб вони могли вирішити необхідні їм послуги.

Агрегатор подій, ймовірно, також є хорошою ідеєю, тому плагіни можуть перекидати події та реагувати на події інших плагінів та хост-програми в нерозділеному вигляді. Ви обов'язково хочете одного!

— Сокіл
джерело