Наш механизм каркаса / правил определяет Поток как элементарную последовательность, в которой пользователю задают вопрос, а затем интерпретируют его или ее результаты, чаще всего приводя к переходу к последующему потоку для получения дополнительных вопросов и обработки.Для целей повторного использования у нас есть шаблон, который мы называем «isNeeded», где статический метод зависает от класса Flow, давая знать другим потокам, нужно ли это в любой точке последовательности в приложении.Например, «Поток обработки платежей» может иметь метод isNeeded, подобный следующему:
public static boolean isNeeded() {
ReasonTracker rt;
if (User has payment due) {
rt = new ReasonTracker(ProcessPaymentFlow.class, true, "payment due");
} else {
rt = new ReasonTracker(ProcessPaymentFlow.class, false, "no payment due");
}
return rt.isNeeded();
}
Итак, если вы находитесь где-то в приложении и хотите узнать, должен ли пользователь получить ProcessPaymentFlow, выможет вызвать метод isNeeded (), а затем отправить пользователя в случае необходимости.Кроме того, существует логирование, поэтому мы можем выяснить, почему некоторые пользователи обращаются к определенному потоку, а другие нет.
Теперь, в качестве модификации нашей платформы, я пытаюсь стандартизировать использование этого метода.В моей голове есть последний статический метод isNeeded (), который вызывает переопределяемый abstract статический метод isNeededInner (), где можно определить случаи, ведение журнала и результаты в OO-принудительным образом.Тем не мение!Я признаю, что это противоречивая концепция.
Не прибегая к хакерским / обманным путям, есть ли способ имитировать концепцию абстрактного статического метода в Java, или я ограничен тем, как мы это уже продумали?Бонус - есть ли способ работать в этом или супер с getClass (), чтобы избежать ручной вставки имени класса для ведения журнала?