Pola desain OOP terbaik untuk urutan operasi

Saya sedang mengerjakan aplikasi, modul yang melakukan operasi keuangan berikut secara berurutan:

Ketika seorang pengguna meminta jumlah tertentu untuk ditransfer ke rekening banknya:

1. periksa apakah ada transaksi yang dapat terjadi sekarang? (transaksi hanya dapat dilakukan selama periode waktu tertentu)
2. periksa apakah pengguna telah meminta jumlah minimum untuk ditarik
3. periksa apakah pengguna memiliki akun default

Hasil dari semua tindakan di atas harus dicatat.

Jika semua kondisi di atas memenuhi, transaksi dilakukan. Di masa depan, mungkin ada beberapa pemeriksaan tambahan.

Pola desain berorientasi objek mana yang paling cocok untuk kasus di atas?

Kedengarannya seperti apa yang Anda cari adalah Rantai Tanggung Jawab . Dalam hal ini Anda dapat memiliki kelas-kelas berikut:

• TransactionValidatorBase kelas dasar abstrak
• TransactionTimeValidator
• TransactionAmountValidator
• TransactionAccountValidator

Itu dirantai bersama untuk menerapkan namun banyak aturan yang Anda tentukan.

Bacaan Lebih Lanjut

• CoR di OODesign.com
• Mengikuti CoR di JavaWorld

Pola yang benar di sini sangat tergantung pada konteks. Sebelum memilih pola tertentu yang harus saya patuhi, saya akan mencoba mencari tahu jawaban atas pertanyaan-pertanyaan itu:

• Apakah diperlukan untuk membuat kombinasi berbeda dari (1,2,3) cek pada saat run-time?
• Apakah mereka memerlukan variabel yang sama untuk melakukan tindakan mereka atau mereka sangat berbeda?
• Seberapa tepat pesan kesalahan seharusnya?
• Jika terjadi kegagalan, apakah pengguna mencoba lagi dari (1) langkah selalu?
• Bagaimana konkurensi ditangani?
• Apakah setiap metode menambahkan sesuatu ke permintaan atau hanya memvalidasi? (katakanlah ID akses default?)

Berdasarkan perasaan usus saya akan kode mereka sebagai metode biasa dengan parameter agregasi untuk kode kesalahan.

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

Mungkin ide yang baik untuk meletakkan DoTransaction di antarmuka "ITransactionValidationStragegy" dan membuat layer tipe-super yang akan berisi kode boilerplate validasi.

Namun, dalam desain ini saya mengasumsikan bahwa logika validasi ditentukan pada waktu kompilasi.

Jika urutan langkah Anda sebagian besar melakukan tugas validasi (seperti yang terlihat Anda), tanpa mengubah input, saya benar-benar akan memikirkan pola "Rantai Tanggung Jawab", sebagaimana dijelaskan dalam jawabannya oleh @pswg

Tetapi karena pertanyaan Anda sedikit lebih umum, saya ingin menambahkan "Pemrosesan saluran pipa" juga, karena dengan yang ini, sebuah langkah akan menghasilkan output yang akan menjadi input untuk langkah berikutnya (sehingga mengubah input asli) .

Berikut adalah dua artikel tentang hal itu:
Pengumpulan pipa oleh Martin Fowler.
Lebih banyak diskusi teoretis tentang polanya

Sementara pola sudah disebutkan di sini, saya akan menyarankan Anda untuk berpikir tentang bagaimana Anda ingin menggunakan yang sama dalam aplikasi Anda, berdasarkan kerangka kerja yang Anda gunakan.

Misalnya, validasi yang ingin Anda lakukan, kemungkinan besar akan terus berubah seiring waktu berjalan (mungkin Anda ingin menambahkan validasi baru di masa depan yang membatasi transaksi hingga 10 hari). Selain itu, Anda mungkin tidak ingin melakukan validasi sebelum layanan bisnis aktual Anda atau kode integrasi masuk. Akan lebih baik, jika Anda dapat menambahkan validasi sebagai yang dapat dikonfigurasi.

Jika Anda menggunakan Struts, menggunakan pencegat mungkin ide yang bagus. Dalam hal musim semi, injeksi kacang sebagai ketergantungan memberi Anda lebih banyak fleksibilitas. Saran saya tidak hanya untuk melihat pola / idiom tetapi juga melihat kerangka kerja yang Anda gunakan untuk membangun aplikasi dan melihat seberapa baik Anda dapat memenuhi kebutuhan Anda dari sudut pandang futuristik.

Menurut pemahaman saya apa pun yang diperlukan dapat dimasukkan ke dalam pola perintah seperti di bawah ini. Desain kelas dapat dilakukan seperti di bawah ini.

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

Kelas Klien Anda akan berisi potongan kode berikut:

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

Ini sesuai dengan pemahaman saya, dengan skenario yang telah diberikan di atas.