Лучший шаблон проектирования ООП для последовательности операций

Я работаю над приложением, модуль которого последовательно выполняет следующие финансовые операции:

Когда пользователь запрашивает перевод определенной суммы на свой банковский счет:

1. проверить, может ли какая-либо транзакция произойти сейчас? (транзакция может быть осуществлена ​​только в течение определенного периода времени)
2. проверьте, запросил ли пользователь минимальную сумму для снятия
3. проверьте, есть ли у пользователя учетная запись по умолчанию

Результат всех вышеперечисленных действий должен быть зарегистрирован.

Если все вышеперечисленное условие удовлетворяет, сделка выполняется. В будущем могут быть некоторые дополнительные проверки.

Какой объектно-ориентированный шаблон проектирования лучше всего подходит для вышеуказанного случая?

Похоже, что вы ищете, это цепь ответственности . В этом случае вы можете иметь следующие классы:

• TransactionValidatorBase абстрактный базовый класс
• TransactionTimeValidator
• TransactionAmountValidator
• TransactionAccountValidator

Они объединены в цепочку, чтобы применить любое количество правил, которые вы укажете.

Furter Reading

• CoR на OODesign.com
• После КР на JavaWorld

Если ваша последовательность шагов выполняет в основном обязанности проверки (как вам кажется), не изменяя входные данные, я действительно подумаю о шаблоне «Цепочка ответственности», как объяснил в своем ответе @pswg

Но поскольку ваш вопрос немного более общий, я хотел бы также добавить «конвейерную обработку», поскольку с этим шагом шаг будет производить выходные данные, которые станут входными данными для следующего шага (таким образом, изменяя исходный ввод) ,

Вот две статьи об этом:
Сборник конвейеров Мартина Фаулера
Более теоретическое обсуждение паттерна

Правильный шаблон здесь действительно зависит от контекста. Прежде чем выбрать какой-то конкретный шаблон, я постараюсь найти ответы на эти вопросы:

• Требуется ли создавать различные комбинации (1,2,3) проверок во время выполнения?
• Нужны ли им одни и те же переменные для выполнения своих действий или они сильно различаются?
• Насколько точными должны быть сообщения об ошибках?
• В случае сбоя пользователь всегда повторяет действие с (1) шага?
• Как обрабатывается параллелизм?
• Каждый метод добавляет что-то к запросу или просто проверяет? (скажем, по умолчанию идентификатор действия?)

Основываясь на интуиции, я бы написал их как простые методы с агрегирующим параметром для кодов ошибок.

public void DoTransaction(IErrorAgregator error, TransactionRequest request)
{
    if(!IsTransactionInCertainTimePeriod(request, error)) return;
    if(!IsTransactionAmountInUserBounds(request, error)) return;
    if(!UserHaveDefaultAccount(request, error)) return;
    bankingTransactor.PerformTransaction(request);
}

Возможно, было бы неплохо поместить DoTransaction в интерфейс «ITransactionValidationStragegy» и создать супертип слоя, который будет содержать шаблонный код проверки.

Однако в этом проекте я предполагаю, что логика проверки определяется во время компиляции.

Хотя шаблоны уже упоминались здесь, я бы посоветовал вам подумать о том, как бы вы хотели использовать то же самое в своем приложении, основываясь на используемых вами платформах.

Например, валидация, которую вы хотели бы сделать, скорее всего, будет меняться с течением времени (возможно, вы захотите добавить новую валидацию в будущем, которая ограничивает транзакции до 10 в день). Кроме того, вы, возможно, не захотите выполнять проверку до того, как начнет действовать ваш фактический бизнес-сервис или код интеграции. Было бы хорошо, если бы вы могли добавлять проверки как настраиваемые.

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

Насколько я понимаю, все, что требуется, может быть встроено в шаблон команды, как показано ниже. Дизайн класса может быть сделан согласно ниже.

interface Transaction{
void performAction();
}

class Banking{

void moneyValidation(){
//Validate Here
}

void timeValidation(){
//validate Here
}
}

class TimeValidation implements Transaction{

public Banking bank;

public TimeValidation (Banking bnk){
bank=bnk;
}

void performAction(){
bnk.timeValidation();
}


class MoneyValidation Implements Transaction{

public Banking bank;

public MoneyValidation(Banking bnk;){
bank=bnk;
}

void performAction(){
bnk.moneyValidation();
}
}


class Control{

private List val_list=new ArrayList();

void storeValidation(Transaction trans){
val_list.add(trans);
trans.performAction(val_list.getFirstAndRemove());
}
}

//Same for other validation classes

Ваш класс Client будет содержать следующий фрагмент кода:

Banking bnk = new Banking();
MoneyValidation m_val = new MoneyValidation (bnk);
TimeValidation t_val = new TimeValidation (bnk);
Control ctrl = new Control();
ctrl.storeValidation(m_val);
ctrl.storeValidation(t_val);

Это, как я понимаю, со сценарием, который был приведен выше.