Будь-яка практична альтернатива моделі сигналів + слотів для програмування графічного інтерфейсу?

Більшість інструментаріїв GUI в даний час використовують модель Signals + Slots. Це було Qt та GTK +, якщо я не помиляюся, хто став першопрохідцем.

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

Зараз, наскільки я знаю, ця конструкція використовується в більшості сучасних наборів інструментів. Є Qt, GTK +, FLTK тощо. Є Java Swing. C # навіть має мовну особливість для нього (події та делегати), і Windows Forms був розроблений для цього дизайну. Фактично, за останнє десятиліття ця конструкція для програмування GUI стала своєрідним неписаним стандартом. Оскільки це збільшує продуктивність і забезпечує більшу абстракцію.

Однак моє питання:

Чи є альтернативний дизайн, паралельний чи практичний для сучасного графічного програмування?

тобто дизайн сигналів + слотів - єдиний практичний у місті? Чи можливо зробити програмування GUI будь-яким іншим дизайном? Чи побудовані будь-які сучасні (бажано успішні та популярні) набори інструментів графічного інтерфейсу на альтернативному дизайні?

Хоча я б не називав це все таким популярним, завжди існує реактивне програмування для графічних інтерфейсів, особливо функціонального реактивного програмування , як реалізовано, наприклад, .NET Rx Framework , а також декількома наборами інструментів на дещо більш езотеричних мовах / платформах , як - от реактивний-банан або FrTime , для Haskell і Racket відповідно.

Це моя улюблена тема, і я протягом декади (70-х до '86) думав, що наявність графічного інтерфейсу, що складається з об'єктів, які реагують на події, - це лише правильний спосіб зробити це.

Тоді я натрапив на інший спосіб зробити це описаним тут і з проектом sourceforge тут .

Коротше кажучи, проблема об’єктів полягає в тому, що вони зберігаються, і якщо ви пишете код для їх створення, вам також потрібно написати код, щоб поступово їх змінювати, якщо потрібні зміни, і якось отримувати повідомлення до них і від них. Хіба не було б добре, якби ви могли просто намалювати те, що хотіли, а потім перефарбувати його, якщо хочете чогось іншого, і не потрібно турбуватися про збереження попередніх об’єктів? Не було б також непогано, якби ніколи не довелося писати код для обробки повідомлень, адже це все робиться під кришкою?

Ось що робить цей пакет. Для простих діалогів він зберігає порядок величини в коді. Для складних діалогів, що динамічно змінюються, це робить їх можливим.

PS Я робив це лише для інтерфейсів настільних ПК та інтерфейсів віддаленого терміналу, а не для користувальницьких інтерфейсів веб-браузера. Я впевнений, що це можливо, але я не мав можливості спробувати це.

Щодо цього є два різних способи:

1. Запропонуйте кожному віджету відкрити детальний механізм підписки (сигнал / слот, спостерігач / спостереження, подія / делегат), а клієнтський код підписується та вживайте відповідних заходів.
2. Вбудований віджет проти абстрагування даних, які він представляє, і має клієнтський код реалізувати цю абстракцію.

Ось приклад другого підходу:

interface Action {
     void execute();
     Bool isEnabled();
     Null<String> description();//used for tooltip
}
interface LabledAction extends Action {
     String getName();
}

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

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

У кількох системах управління використовується підхід до бази даних - кожен елемент управління пов'язаний з файлом у базі даних, щоб Gui завжди відображав стан бази даних. Гаки БД використовуються для запуску функцій, коли значення змінюється.