在禁用的GUI选项中添加额外检查是一个好习惯吗?

时间:2011-01-05 14:53:34

标签: user-interface language-agnostic defensive-programming

我指的是以下内容:

void setup_gui()
{
    if (some_condition)
        some_button.disable();

    ...
}

void some_button_click()
{
    // Is this a good practice?
    if (some_condition)
        return;

   ...
}

添加该检查可确保程序不会运行该操作,但也可以将其视为隐藏错误(some_button_click()一定不能运行。)

那么,您如何看待它?它是一种安全的编码实践还是隐藏错误?

4 个答案:

答案 0 :(得分:2)

防御性编程与防御性驾驶一样合理。

从单独的关注方面考虑这一点可能会有所帮助。一个问题是演示文稿。另一个可能是一组业务规则。在两个地方进行相同的检查是合理的。

您希望在表示层中进行检查以与用户进行通信。

您可能还想在表示层下面进行检查:

  • 为表示层中的当前和未来错误辩护。
  • 如果表示层下面的代码在别处重复使用。
  • [来自mvds的评论]如果自启用或禁用控件后条件可能会发生变化。

编辑:David Heffernan在下面的DRY关注可以通过一次定义条件并在其他地方访问它来轻松解决。

void setup_gui()
{
    some_button.setEnabled( context.isThisActionAvailable() );

    ...
}

void some_button_click()
{
    if ( context.isThisActionAvailable() )
        return;

   ...
}

答案 1 :(得分:1)

我不带这条带括号的方法。问题是你通过双重使用some_condition违反了DRY原则。在一个地方而不是另一个地方改变这一切都很容易。

当然,在这个组成的例子中,some_condition非常简单,但实际上它通常要复杂得多。

如果您不能信任您的GUI框架在请求阻止时阻止操作,那么您需要修复框架。

答案 2 :(得分:0)

它可以被认为是安全编码,也可以被认为是隐藏了一个bug。这是您重新评估程序逻辑的时候。如果可能,始终最好避免代码冗余。如果您的程序可以通过确保程序的实际逻辑正常工作并按预期正常工作而不需要检查两次,那就更好了。

当然,如果你匆忙这是一个快速解决方案并且它有效,但它在程序的其他地方充满了糟糕的设计和/或逻辑。

答案 3 :(得分:0)

some_button_click()中的静默返回可能隐藏了一个错误。我要么根本不做检查,要么大声和猛烈地撞击。