Появилась у меня некая мета-идея... Но прежде чем детализировать её, создавать реализацию, хочу спросить народ, может есть уже что-то подобное, известная парадигма, подход (плз. не используем в ответах слово «Паттерн» - тошнит)
Сейчас пишу на Python/Django, и в первую очередь ниже описываемая идея относиться к ним, но и для других языков это актуально.
Короче, программирование пользовательской логики, если мы говорим о enterprise-приложениях, это заполнение каких-то форм данными, и последующее оперирование полученными данными. Причём это не всегда формы в привычном нам понимании, иногда формы прячуться за красивым ГИС-интерфейсом. Суть всегда одна и та-же, программа предоставляет пользователю некий ГУЙ, в котором пользователь должен сделать что-то, заполнить интерфейс данными. По заполнению интерфейса инициируется какой-то код, выполняющий непосредственно логику. Далее, результат отображается либо здесь-же, либо осуществляется переход к следующему интерфейсу.
Большие формы хороши своей концептуальной целостностью, но плохи перегруженностью кодом и отсутствием повторного использования. У маленьких форм есть недостаток, ведь если мы выполняем какое-то действие, для которого нужно заполнить несколько маленьких форм, нужно обеспечить не только правильность данных для каждой формы, но и общую логическую согласованность всей цепочки форм.
Традиционно эта проблема решается через жёсткое зашитие в код вызовов форм и использования в самих формах кода по контролю за логической согласованностью.
Возникла у меня мысль, сделать такую систему, которая бы обеспечивала автоматическую валидацию больших логических операций внутри приложения. Этакий конечный автомат, описываемый отдельно от основной логики. Есть мысль что он должен предоставлять такой функционал:
1. Описывать какую-то логическую мета-операцию, состоящую из под-операций, и предоставлять имя для неё
2. Предоставлять требования к последовательности выполнения под-операций
3. Предоставлять требования к наличию определённых данных, перед тем как будет выполнена определенная под-операция
4. Предоставлять какие-то очень тривиальные методы использования себя. Например через декораторы для джанговских view.
ПСЕВДОКОД:
Опишем_тут_мета-операцию, (из таких-то под-операций, с такими-то требованиями к данным), с именем "Добавить клиента"
@декоратор_для_"Добавить клиента"_под-операция1
def view1(request):
....
@декоратор_для_"Добавить клиента"_под-операция2
def view222(request):
....
По итогу, view будут вызваны только если соблюдены все условия
