Melhor padrão de design de OOP para uma sequência de operações

Estou trabalhando em um aplicativo, cujo módulo executa as seguintes operações financeiras sequencialmente:

Quando um usuário solicita que uma certa quantia seja transferida para sua conta bancária:

1. verificar se alguma transação pode acontecer agora? (a transação pode ser realizada apenas durante um determinado período)
2. verifique se o usuário solicitou a retirada de um valor mínimo
3. verifique se o usuário tem alguma conta padrão

O resultado de todas as ações acima deve ser registrado.

Se todas as condições acima estiverem em conformidade, a transação é realizada. No futuro, pode haver algumas verificações adicionais.

Qual padrão de design orientado a objetos deve ser mais adequado para o caso acima?

Parece que o que você está procurando é uma Cadeia de Responsabilidade . Nesse caso, você pode ter as seguintes classes:

• TransactionValidatorBase classe base abstrata
• TransactionTimeValidator
• TransactionAmountValidator
• TransactionAccountValidator

Que são encadeados para aplicar as regras que você especificar.

Furter Reading

• CoR em OODesign.com
• Seguindo o CR no JavaWorld

O padrão correto aqui é realmente depende de um contexto. Antes de escolher qualquer padrão em particular, tentarei encontrar respostas para essas perguntas:

• É necessário criar combinações diferentes de verificações (1,2,3) em tempo de execução?
• Eles precisam das mesmas variáveis ​​para executar suas ações ou são muito diferentes?
• Qual a precisão das mensagens de erro?
• Em caso de falha, o usuário tenta sempre novamente a partir da (1) primeira etapa?
• Como a simultaneidade é tratada?
• Cada método adiciona algo à solicitação ou simplesmente valida? (diga ID de conta padrão?)

Baseado em um pressentimento, eu os codificaria como métodos simples, com agregação de parâmetros para códigos de erro.

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);
}

Pode ser uma boa ideia colocar DoTransaction na interface "ITransactionValidationStragegy" e criar um super-tipo de camada que conterá o código de validação.

No entanto, neste design, estou assumindo que a lógica de validação é determinada em tempo de compilação.

Se sua sequência de etapas estiver cumprindo principalmente tarefas de validação (como você parece), sem alterar as entradas, eu pensaria realmente no padrão "Cadeia de responsabilidade", conforme explicado em sua resposta por @pswg

Mas como sua pergunta é um pouco mais genérica, eu gostaria de adicionar também o "Processamento de pipeline", já que com essa, uma etapa produziria uma saída que se tornaria a entrada para a próxima etapa (alterando a entrada original) .

Aqui estão dois artigos:
Coleção de pipeline de Martin Fowler
Mais discussões teóricas sobre o padrão

Embora os padrões já sejam mencionados aqui, sugiro que você pense em como gostaria de usar o mesmo em seu aplicativo, com base nas estruturas que você está usando.

Por exemplo, a validação que você gostaria de fazer provavelmente continuará mudando à medida que o tempo avança (pode ser que você queira adicionar uma nova validação no futuro que restrinja as transações a 10 por dia). Além disso, você pode não querer fazer a validação antes que o código de serviço ou integração de negócios real seja ativado. Seria bom se você pudesse adicionar as validações como configuráveis.

Caso você esteja usando Struts, o uso de interceptores pode ser uma boa ideia. No caso da primavera, a injeção de feijão como dependência oferece mais flexibilidade. Minha sugestão é não apenas olhar para os padrões / expressões idiomáticas, mas também para a estrutura que você usa para criar o aplicativo e ver a melhor forma de se adequar às suas necessidades do ponto de vista futurista.

De acordo com o meu entendimento, tudo o que for necessário pode ser ajustado ao padrão de comando como abaixo. O design da classe pode ser feito conforme abaixo.

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

Sua classe Client conterá o seguinte snippet de código:

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);

Isto é de acordo com o meu entendimento, com o cenário que foi dado acima.