如何界定「的isValid」功能以理

我想有些州在我的文件生成程序在一個點模型，：如何界定「的isValid」功能以理

我要檢查的數據的當前狀態
如果數據是有效的我要繼續
否則我要告知用戶原因，爲什麼我不能繼續

一個psudocode會是這樣：

if(isValid()){ 
    writeFile() 
} else { 
    switch(getReason()){ 
     case FAIL1: doSomething1(); 
      break; 
     case FAIL2: doSomething2(); 
      break; 
     case FAIL3: doSomething3(); 
      break; 
    } 
}

不知道這樣的做法是正確的，希望您的意見/意見。其中：總共有少於10個錯誤狀態，並且在給定時間只有一個錯誤狀態適用。

來源

2016-08-21 Suryavanshi

取決於有多少錯誤狀態以及是否可以同時應用多個錯誤狀態。這個問題沒有明確說明。 –

更新了規範 – Suryavanshi

我會給你一個Reason和enum把你的原因，所有的特定信息出現。然後，您可以使用來自原因的特定信息來參數化doSomething方法。聽起來像這樣可能是String。通過這種方法，擴展代碼變得更加容易。的代碼可能看起來像：

if(isValid()){ 
    writeFile() 
} else { Reason reason = getReason(); 
    doSomething(reason.getMessage()); 
}

有了您的枚舉Reason

enum Reason { 
    REASON1("message1"), REASON2("message2")/* ... */; 

    private String message; 

    private Reason(String message) { 
     this.message = message; 
    } 

    public String getMessage() { 
     return message; 
    } 

}

來源

2016-08-21 07:25:48 garnulf

從garnulf的想法在一個良好的方向前進;但它仍然不是OO術語中的一個很好的解決方案。

事情是：你已經提到的關鍵概念，這裏重要的：狀態，如狀態機。

你真的想在這裏使用多態：

abstract class Reason() { 
    String getMessage() { // just to show that there might be some shared code 
    abstract void doSomething();

那麼你將有你的理由類不同的子類;而在最後，你的客戶端代碼歸結爲：

getReason().doSomething();

因爲每一個理由都知道什麼辦本身！當然，這可能需要一些進一步的思考 - 取決於這些不同的錯誤原因是真的。

關鍵的一點是：你真的想避免任何形式的過度枚舉或字符串值的切換。如果有的話，你將這些開關隱藏在工廠內部，返回一些抽象類/接口thingy（工廠爲你創建一個具體的子類/實現）。

來源

2016-08-21 07:55:39 GhostCat

在有問題的情況下，「Reason」無法確定進一步的操作，我們是否仍然可以避免「切換」到「原因」？ – Suryavanshi

@Suryavanshi好吧，可能不容易。但更具體的建議，你應該提高你的問題;也許舉一個具體的錯誤條件的例子，以及你想到的那種反應。 – GhostCat

錯誤狀態可以是任何東西，比如說一個「訂單處理模塊」可以報告訂單失敗，因爲a。庫存不足'或'b。付款失敗「。在這個特定的例子中，「訂單處理模塊」不會對錯誤狀態的反應負責，它只能通知訂單是成功還是失敗。如果訂單失敗了，那麼爲什麼！ – Suryavanshi

如何界定「的isValid」功能以理

回答

相關問題