Il miglior modello di progettazione OOP per una sequenza di operazioni

Sto lavorando a un'applicazione, un modulo del quale esegue le seguenti operazioni finanziarie in sequenza:

Quando un utente richiede che un determinato importo venga trasferito sul suo conto bancario:

1. controlla se qualche transazione può avvenire ora? (la transazione può essere eseguita solo durante un certo periodo di tempo)
2. verificare se l'utente ha richiesto il prelievo di un importo minimo
3. controlla se l'utente ha un account predefinito

Il risultato di tutte le azioni sopra riportate deve essere registrato.

Se tutte le condizioni di cui sopra soddisfano, la transazione viene eseguita. In futuro potrebbero esserci ulteriori controlli.

Quale modello di design orientato agli oggetti dovrebbe essere più adatto al caso sopra?

Sembra che quello che stai cercando sia una catena di responsabilità . In questo caso potresti avere le seguenti classi:

• TransactionValidatorBase classe base astratta
• TransactionTimeValidator
• TransactionAmountValidator
• TransactionAccountValidator

Che sono concatenati insieme per applicare qualunque regola tu specifichi.

Furter Reading

• CoR su OODesign.com
• A seguito del CdR su JavaWorld

Se la tua sequenza di passaggi sta svolgendo principalmente compiti di convalida (come sembra che tu sia), senza mutare gli input, penserei davvero al modello "Catena di responsabilità", come spiegato nella sua risposta di @pswg

Ma poiché la tua domanda è un po 'più generica, vorrei aggiungere anche "Elaborazione pipeline", poiché con questo, un passaggio produrrebbe un output che diventerebbe l'input per il passaggio successivo (mutando così l'input originale) .

Ecco due articoli a riguardo:
Collezione Pipeline di Martin Fowler
Altre discussioni teoriche sul modello

Il modello corretto qui dipende davvero da un contesto. Prima di scegliere uno schema particolare a cui attenermi, cercherò di trovare le risposte a queste domande:

• È necessario creare diverse combinazioni di (1,2,3) controlli in fase di esecuzione?
• Hanno bisogno delle stesse variabili per eseguire le loro azioni o sono molto diverse?
• Quanto devono essere precisi i messaggi di errore?
• In caso di errore, l'utente riprova sempre dal (1) primo passaggio?
• Come viene gestita la concorrenza?
• Ogni metodo aggiunge qualcosa alla richiesta o semplicemente convalida? (dire ID acct predefinito?)

Basandomi su un istinto, li codificherei come semplici metodi con aggregando i parametri per i codici di errore.

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

Potrebbe essere una buona idea inserire DoTransaction nell'interfaccia "ITransactionValidationStragegy" e creare un super-tipo di livello che conterrà il codice del bollettino di convalida.

Tuttavia, in questo progetto presumo che la logica di validazione sia determinata al momento della compilazione.

Mentre i modelli sono già menzionati qui, ti suggerisco di pensare a come vorresti usare lo stesso nella tua applicazione, in base ai framework che stai usando.

Ad esempio, la convalida che vorresti fare, molto probabilmente continuerà a cambiare man mano che il tempo avanza (potresti voler aggiungere una nuova convalida in futuro che limita le transazioni a 10 al giorno). Inoltre, potresti non voler eseguire la convalida prima che il tuo vero servizio aziendale o il codice di integrazione entrino in funzione. Sarebbe positivo se puoi avere le convalide aggiunte come configurabili.

Nel caso in cui si utilizzi Struts, l'utilizzo di intercettori potrebbe essere una buona idea. In caso di primavera, l'iniezione di fagioli come dipendenza ti dà maggiore flessibilità. Il mio suggerimento non è solo quello di guardare i modelli / modi di dire, ma anche il framework che usi per costruire l'applicazione e vedere come puoi adattarti al meglio alle tue esigenze da un punto di vista futuristico.

Secondo la mia comprensione tutto ciò che è richiesto può essere inserito nel modello di comando come di seguito. La progettazione della classe può essere eseguita come di seguito.

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

La tua classe Client conterrà il seguente frammento di codice:

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

Questo è secondo la mia comprensione, con lo scenario che è stato dato sopra.