Чи має сенс застосовувати принципи в Redux до мов ОО?

Redux по суті є функціональним програмуванням, і це має багато сенсу. По мірі повернення до мови OOP, що не належить JavaScript, я хотів би застосувати ті самі принципи, як об'єкт єдиного стану, редуктори, які діють на частини цього стану, бізнес-рівень семантичних дій для зміни стану.

Мій проект знаходиться на C ++, і я хочу знати, чи є сенс спробувати застосувати функціональний підхід в стилі редукс для проектування програми. Продуктивність не надто важлива для цього додатка, але ремонтопридатність є.

З якими труднощами я зіткнувся б у створенні такого додатка?

Додам, що це не додаток для графічного інтерфейсу. І якщо подумати про це більше, можливо, redux зменшив перевагу в програмі, що не є графічним інтерфейсом, оскільки немає жодного прямого візуального ефекту від оновлення стану програми.

Функціональні стилі програмування, як правило, можна використовувати багаторазово майже з будь-якого місця з правильним настроєм. Загальна ідея застосування парадигм перехресних мов - це те, про що Стів МакКоннелл посилається в Code Complete як "програмування на мову". Я здебільшого хотів зазначити, що бажання застосовувати уроки, вивчені міжмовною та перехресною парадигмою, є справді позначкою того, хто сприймає мову як середовище вираження. Дивовижно, скільки розробників ніколи не досягають цієї точки.

Як ви зазначаєте, філософія Redux орієнтована на розвиток інтерфейсу. Важко передбачити занадто багато сценаріїв, де відстеження стану дельти є корисним у середовищах, що не користуються інтерфейсом. Це дійсно залежить від вашої проблеми. Якщо такий підхід полегшує розуміння та підтримку загального рішення, мабуть, це хороший варіант. Загальний підхід, який застосовує Redux, дуже схожий на журнал транзакцій у більшості RDBMS, тому цілком може бути правдою, що такий підхід існував до JavaScript.