Mẫu thiết kế OOP tốt nhất cho chuỗi hoạt động

Tôi đang làm việc trên một ứng dụng, một mô-đun thực hiện các hoạt động tài chính sau đây một cách tuần tự:

Khi người dùng yêu cầu một số tiền nhất định được chuyển vào tài khoản ngân hàng của mình:

1. kiểm tra xem có giao dịch nào có thể xảy ra bây giờ không? (giao dịch chỉ có thể được thực hiện trong một khoảng thời gian nhất định)
2. kiểm tra xem người dùng có yêu cầu rút số tiền tối thiểu không
3. kiểm tra xem người dùng có tài khoản mặc định nào không

Kết quả của tất cả các hành động trên nên được ghi lại.

Nếu tất cả các điều kiện trên thỏa mãn, giao dịch được thực hiện. Trong tương lai, có thể có một số kiểm tra bổ sung.

Những mẫu thiết kế hướng đối tượng nên phù hợp nhất cho trường hợp trên?

Nghe có vẻ như những gì bạn đang tìm kiếm là một Chuỗi trách nhiệm . Trong trường hợp này, bạn có thể có các lớp sau:

• TransactionValidatorBase lớp cơ sở trừu tượng
• TransactionTimeValidator
• TransactionAmountValidator
• TransactionAccountValidator

Điều đó được kết nối với nhau để áp dụng tuy nhiên nhiều quy tắc bạn chỉ định.

Đọc nhanh hơn

• CoR trên OODesign.com
• Theo CoR trên JavaWorld

Mô hình chính xác ở đây thực sự phụ thuộc vào một bối cảnh. Trước khi chọn bất kỳ mẫu cụ thể nào để bám vào, tôi sẽ cố gắng tìm ra câu trả lời cho những câu hỏi đó:

• Có bắt buộc phải tạo các kết hợp khác nhau (1,2,3) kiểm tra trong thời gian chạy không?
• Họ có cần các biến giống nhau để thực hiện hành động của mình hay chúng khác nhau rất nhiều?
• Làm thế nào chính xác các thông báo lỗi nên được?
• Trong trường hợp thất bại, người dùng thử lại từ (1) bước thứ nhất luôn?
• Làm thế nào đồng thời được xử lý?
• Có phải mỗi phương pháp thêm một cái gì đó vào yêu cầu hoặc chỉ đơn giản là xác nhận? (nói id acct mặc định?)

Dựa trên cảm giác ruột tôi sẽ mã hóa chúng như một phương thức đơn giản với tham số tổng hợp cho mã lỗi.

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

Có thể là một ý tưởng tốt để đặt DoTransaction trong giao diện "ITransactionValidationStragegy" và tạo một loại siêu lớp sẽ chứa mã nồi hơi xác thực.

Tuy nhiên, trong thiết kế này tôi giả định rằng logic xác thực được xác định tại thời điểm biên dịch.

Nếu trình tự các bước của bạn thực hiện hầu hết các nhiệm vụ xác thực (trông giống như bạn), mà không làm thay đổi các yếu tố đầu vào, tôi thực sự nghĩ về mẫu "Chuỗi trách nhiệm", như được giải thích trong câu trả lời của @pswg

Nhưng vì câu hỏi của bạn chung chung hơn một chút, tôi cũng muốn thêm "Xử lý đường ống", vì với câu hỏi này, một bước sẽ tạo ra một đầu ra sẽ trở thành đầu vào cho bước tiếp theo (do đó làm thay đổi đầu vào ban đầu) .

Dưới đây là hai bài viết về nó:
Bộ sưu tập đường ống của Martin Fowler
Thảo luận thêm về lý thuyết về mẫu

Mặc dù các mẫu đã được đề cập ở đây, tôi sẽ đề nghị bạn suy nghĩ về cách bạn muốn sử dụng tương tự trong ứng dụng của mình, dựa trên các khung bạn đang sử dụng.

Ví dụ: xác thực bạn muốn thực hiện, rất có thể sẽ tiếp tục thay đổi và khi thời gian tiến triển (có thể bạn muốn thêm xác thực mới trong tương lai, điều này hạn chế giao dịch xuống còn 10 mỗi ngày). Ngoài ra, bạn có thể không muốn thực hiện xác nhận trước khi dịch vụ kinh doanh thực tế hoặc mã tích hợp của bạn bắt đầu. Sẽ tốt nếu bạn có thể xác thực được thêm vào dưới dạng cấu hình.

Trong trường hợp bạn đang sử dụng Struts, sử dụng các thiết bị chặn có thể là một ý tưởng tốt. Trong trường hợp của mùa xuân, đậu tiêm làm phụ thuộc cho bạn linh hoạt hơn. Đề nghị của tôi không chỉ là xem xét các mẫu / thành ngữ mà còn xem xét khuôn khổ mà bạn sử dụng để xây dựng ứng dụng và xem bạn có thể phù hợp nhất với yêu cầu của bạn như thế nào từ quan điểm tương lai.

Theo sự hiểu biết của tôi, bất cứ điều gì được yêu cầu có thể được gắn vào mẫu lệnh như dưới đây. Thiết kế lớp có thể được thực hiện theo dưới đây.

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

Lớp Client của bạn sẽ chứa đoạn mã sau:

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

Theo hiểu biết của tôi, với kịch bản đã được đưa ra ở trên.