从接口方法中排除类的最有效的方法

到目前为止，我已经使用下面的代码来限制某些方法的应用程序到某些类的实例。例如，使用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

从接口方法中排除类的最有效的方法

回答

相关问题