如何解釋具有複雜限制的操作失敗

我正在實施一個系統，客戶可以使用憑證獲取購物折扣。如果憑證可以用於某種購買取決於幾種情況。如何解釋具有複雜限制的操作失敗

例如：

適當的優惠券代碼 - 是代碼是否正確？
有效範圍 - 憑證仍然有效嗎？
憑證可以與購買類型一起使用嗎？
允許組合 - 優惠券是否可以與其他優惠券結合使用？
更多...

也有一些更多的是需要檢查複雜的限制。如果一個或多個限制不滿足，客戶無法使用優惠券，我想通知他/她有關「無法使用」的解釋「爲什麼」，例如：

「You can'不要使用這張優惠券，因爲它已經過時了。「

我現在的問題是：你會如何執行檢查？
在自己的類中實現每個限制，鏈接它們並拋出異常？（這裏的問題，可能會執行幾個相同的數據庫查詢）在一個單一方法中實現所有限制？（真的，爲什麼？）一般來說，如果實施一種機制，您必須通知客戶有關如果將複雜限制應用於某個操作時失敗的詳細信息？

謝謝，

來源

2010-01-26 Chris

就我個人而言，我會在一個方法中執行檢查。憑證進入，出錯消息（如果有的話）。

這將保持所有代碼隱藏在該方法後面，並使維護變得容易。一個地方檢查是否出現問題，一個地方修改添加新東西等

如果我們正在談論大量的測試，而不是改變方法到一個類（但再次責任在一個地方，沒有複雜性散佈在各地）。

只是我的兩分錢。

來源

2010-01-26 13:57:06

我將抽象的意圖，以便它並不重要它是如何實現的，還是怎麼着源代碼的組織。在基本層面上，您擁有的是一組檢查器，生成一系列失敗解釋。

的僞代碼將主要是：

let reasons be a new, empty collection of failure reasons 
let checkers be the list of relevant checkers 

for each checker in checkers 
    if checker passes, continue 
    if checker fails, add explanation to reasons 

if number of reasons is zero, 
    voucher is valid, success 
if number of reasons > zero, 
    the voucher is invalid, format each element in reasons for display to the user

有了這個邏輯，不要緊的跳棋是如何組織的，只要他們能夠獲得通過的這部分代碼在一個列表。你可以有一個單一的方法與許多檢查，可能會增加很多原因。你可以有許多類，每個檢查器列表中有一個實例。至關重要的是，實際的檢查人員與此邏輯脫鉤，隨時可以使用不同的檢查人員（考慮業務規則變化或不同地區的不同規則）。

根據您的語言，這至少會涉及抽象用於檢查者的類型。

從那開始。如果您發現相同的數據庫查詢，則開始考慮用於運行檢查程序集的緩存。

至於跳棋是如何在源級別上組織的......沒關係。只有抽象纔會。一旦你提供了一個可以隱藏起來的抽象級別，細節就相當靈活了。

優點：

執行檢查不關心實際的，具體的檢查（這可能會改變根據業務規則）位。
無論您想要如何組織跳棋，您都可以組織跳棋：在一個源文件中一起定義跳棋，或者根據其他方案進行分組。它還允許自由分離出一個檢查器來進行測試。
集合和漂亮的格式化只需執行一次，無論檢查的類型或數量如何。

缺點：

這需要時間的前期做設計抽象的一份體面的工作。這可能會在稍後得到回報。
有一層間接性可能使其更難以理解，並追查正在進行的實際檢查。靈活性不利於可理解性。這些是你必須考慮的情況。在我看來，優惠券的規則似乎是隨着時間的推移可能會改變的東西，這裏的抽象並不難理解，所以我認爲這是值得的。

我花時間在Java中編寫了一個例子，但它確實沒有增加太多。如果試圖從抽象的角度思考，實際的機制並不重要。

來源

2010-01-26 22:43:56 Grundlefleck

我最近處理了一個類似的問題，檢查使用一步結帳頁面下單。最後，我們發現生成一個包含所有相關「問題」（我們用簡單的類包含代碼，顯示消息等）的數組而非描述遇到的第一個問題的字符串更有用。

這適用於返回一組相關問題的單個檢查器方法。主要的檢查器方法調用更具體的檢查器方法來構建數組。如果其他人已經失敗，它可以選擇跳過一些檢查。

來源

2010-01-26 23:55:15 anyaelena

如何解釋具有複雜限制的操作失敗

回答

相關問題