從接口方法中排除類的最有效的方法

到目前爲止，我已經使用下面的代碼來限制某些方法的應用程序到某些類的實例。例如，使用ItemListener，但是這可能被應用到很多東西，從接口方法中排除類的最有效的方法

public class mListener implements ItemListener { 
    public void itemStateChanged(ItemEvent e) { 

     if (!(e.getItemSelectable instanceof JCheckBox)) { //again, JCheckBox was chosen arbirtarily 
      System.err.println("mListener can only be applied to a JCheckBox"); 
      return; 
     } 

    } 
}

然而，在對甲骨文的Java教程的幾個地方，我看到了下面的代碼

public class mListener implements ItemListener { 
    public void itemStateChanged(ItemEvent e) { 
     JCheckBox box = null; 

     try { 
      box = (JCheckBox) e.getItemSelectable(); 
     } catch (ClassCastException ex) { 
      System.err.println("mListener can only be applied to a JCheckBox"); 
      return; 
     } 

    } 
}

是哪個鎖定不希望應用方法的類的最佳方法？實現接口的情況尤其如此，其中參數無法更改。

來源

2012-06-11 gobernador

你的問題是什麼？ –

實際目標是什麼？這不像JVM隨機將聽衆應用於任意元素 - 您是否試圖避免犯錯誤？這是代替規格/測試嗎？ –

對不起，在我輸入完畢之前發貼 – gobernador

在這兩種情況下，這是編程錯誤。監聽器被不適當地添加。對此的正確迴應幾乎肯定不僅僅是打印出可能永遠不會被看到的消息 - 這是一個例外。

簡單的轉換會給你這個異常，而你沒有任何工作，所以只能無條件投射，並且不要掩蓋編程錯誤。

來源

2012-06-11 15:59:25

第二個版本是邪惡的，因爲它使用流量控制的例外。閱讀Effective Java by Joshua Bloch以瞭解爲什麼這是不好的（項目57：「僅爲例外條件使用例外」）。

來源

2012-06-11 15:58:44

我不確定我是否會調用流控制 - 它基本上是一個斷言，不應該在部署的代碼中可見，因爲它是源代碼級別的問題。 –

@DaveNewton那麼爲什麼不去'assert e.getItemSelectable（）instanceof JCheckBox'？ –

@isbadawi我不知道 - 詢問OP。我只是不考慮這個流量控制，因爲它是一個編程錯誤，而不是邏輯錯誤。 –

答案可能是這樣的：捕獲ClassCastException允許e爲JCheckBox的任何子類，而使用instanceof僅將其限制爲JCheckBox。

來源

2012-06-11 16:02:04 gobernador

從接口方法中排除類的最有效的方法

回答

相關問題