为什么要使用基类型声明方法参数?

本文关键字：声明 方法 参数 类型 基类 为什么 | 更新日期: 2023-09-27 18:16:25

我声明了一个简单的方法来尝试将文本框中的输入转换为int类型，如下所示:

int TryConvertTextToInt(TextBox box)
{
    //do try catch
}

我的IDE (SharpDevelop)试图给我一些重构建议;具体来说，可以将box参数声明为基类型(工具提供的两个选项是TextBoxBase和Control)。我知道我不想将此方法用于除TextBox之外的任何东西，如果我确实改变了主意，特定的参数类型将提醒我可能需要稍微更改该方法以适应更大范围的输入。我不认为现在改变类型有什么价值，因为我没有预料到后一种情况，而且这个项目很小。

是否有一个原因，我想这样做，我错过了，或者是IDE只是过分的帮助?

为什么要使用基类型声明方法参数?

在您的特殊情况下，这可能没有太大的区别。假设你要通过一个TextBox，你可能永远不会想通过TextBox以外的任何东西。

然而，在更一般的情况下，最佳实践通常是为方法提供最基本的参数类型和最具体的返回类型。正如您的IDE所建议的那样，这个想法是允许在以后的各种地方使用该方法。

作为一个例子，我们可以看一下集合的经典情况。许多开发人员将编写接受List<T>作为参数的代码，然后通过它执行foreach。如果他们只处理List<T>，那就太好了，但是如果他们想要扩展到其中加入一些LINQ表达式，他们就会突然处理IEnumerable<T>。在foreach循环中不需要List<T>，但是因为他们没有使用基类(或者接口，在这种情况下，这通常是更好的)，他们现在要么必须改变方法签名——一个没有破坏性的改变，但仍然不是一个好的改变——或者在他们的LINQ中添加.ToList()，这破坏了使用LINQ的许多优点(因为突然他们必须在集合中循环可能至少三次)。

你总是想要确保你接受的类或接口是最小的，它仍然提供了你需要的成员。当然，也不要太保守:如果有正确的方法和概括的方法，选择正确的方法，但如果它们是相同的，概括的方法是最好的。

但是，就你的情况而言，我认为这没什么大不了的。使用TextBox提供的其他成员的可能性比将TextBoxBase或Control的其他继承者传递给方法的可能性更大。实际上，这完全取决于您的应用程序。回顾你所拥有的和你所需要的，然后在此基础上建立你对这个警告的回应。在我看来，你很高兴能离开这里，这就是你应该做的。但为了将来的参考，这是一个想法。

参数类型是特定的将提醒我方法可能需要稍微更改以适应更大范围的输入

但是它不需要修改以适应更大范围的输入，所以这个"提醒"会产生误导。您的IDE已经检测到它已经可以容纳它们，因为您在实现中没有做任何特定于textbox的事情。

只有当你打算在将来使它真正特定于textbox时，你才应该忽略这个建议。
相关文章：