Единственное, что я могу себе представить, используя делегаты выражений над классами Java, это то, что всякий раз, когда мой пользовательский класс кода требовал загрузки из пружинных бинов, используя внедрение зависимостей , особенно там, где вы хотите управлять жизненным циклом экземпляра делегирования с помощьюваше приложение, а не движок Camunda.
Проще говоря, используя делегаты выражений, мы можем инициализировать класс делегата так, как мы хотим, используя Spring DI, не позволяя движку Camunda его инициализировать.И воспользуйтесь всеми преимуществами DI.
Сценарий состоит в том, что мы хотим загрузить наш класс делегирования из пружинных бинов, где он требует внедрения зависимостей времени выполнения перед выполнением нашего кода делегирования.Таким образом, мы можем использовать пружинные бины для инициализации других зависимостей объекта и создания бина, ссылающегося на класс делегирования, внедряющего другие инициализированные бины.Например,
<serviceTask id="paymentTask" camunda:delegateExpression="${myPaymentBean}" />
В приведенном выше примере myPaymentBean разрешается из пружины, и это будет экземпляр JavaDelegate, который уже инициализирован с необходимыми зависимостями посредством внедрения зависимостей (DI).Мы использовали DI, потому что наша бизнес-логика должна быть тщательно протестирована перед вводом в эксплуатацию и упростить написание автоматизированных тестов поверх них.
Если вы используете классы Java, то часть инициализации экземпляра будетсделано с помощью механизма camunda, и существует ограничение на наличие общедоступного конструктора по умолчанию.Это очень ограничено, так как большинство практических приложений имеют зависимости и должны быть уже инициализированы перед кодом.Либо вы должны создавать свои зависимости как одиночные (что я никогда не рекомендую), либо использовать фабрики для создания экземпляров перед кодом (что неэффективно и сложнее для тестирования).
Надеюсь, это прояснит ваш вопрос.