重载方法时返回不同类型是一种不好的做法吗?
给出这个例子:
Interface CustomersDao
Function Get(ByVal Id As Integer) As Customer
Function Get(ByVal Filter As Filter) As IList(Of Customer)
End Interface
Public Sub Main()
Dim Customer As Customer = CustomersDao.Get(4)
Dim Filter As New CustomersDao.Filter
Filter.Category = 2
Dim Customers As IList(Of Customer) = CustomersDao.Get(Filter)
End Sub
在同一个方法中返回不同类型是一个不好的做法吗?
Given this example:
Interface CustomersDao
Function Get(ByVal Id As Integer) As Customer
Function Get(ByVal Filter As Filter) As IList(Of Customer)
End Interface
Public Sub Main()
Dim Customer As Customer = CustomersDao.Get(4)
Dim Filter As New CustomersDao.Filter
Filter.Category = 2
Dim Customers As IList(Of Customer) = CustomersDao.Get(Filter)
End Sub
Is it a bad practice to return diferent types in the same method?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
我建议调用第二个
GetAll
。目前,第二个方法返回一个集合并不明显。
您应该努力确保您的课程尽可能明显,并且不包含任何意外的惊喜。
I would recommend calling the second one
GetAll
.Right now, it isn't obvious that the second method returns a collection.
You should strive to ensure that your classes are as obvious as possible and do not contain any unexpected surprises.
不,我想说那很好。
No, I would say that is perfectly fine.
在您的示例中,API 很有意义并且看起来很直观。特别是因为您将函数参数命名为 Id 和 Filter,在我看来,它们分别意味着单值结果和集合。缺点是,在智能感知场景中,您必须检查每个重载以了解它的作用,而不仅仅是查看建议列表中要调用的正确方法。例如
GetSingle(int id)
与GetAll()
与GetSubset(string filter)
我可以想象重载和返回不同类型的场景很快就会变得非常混乱。尤其是当您开始引入一些技巧来解决 API 的既定用法时。
In your example the API makes sense and looks intuitive. Especially since you named the function arguments Id and Filter which, IMO, imply a single value result and a collection respectively. The drawback being that in an intellisense scenario you would have to examine each overload to see what it does rather just seeing the proper method to call in the suggested list. E.g.
GetSingle(int id)
vs.GetAll()
vs.GetSubset(string filter)
I could imagine scenarios where overloading and returning different types could quickly become very confusing. Especially if you start introducing hacks to work around an established usage of the API.
是的,我认为这是一种不好的做法。
尝试在 .NET Framework 中找到返回不同类型的重载,我想不出一个 。
更新
.NET Framework 中有一些方法,例如 DateTime.Subtract() 但它们是例外而不是规则,并且只有意图完全明显的情况。
Yes, I believe it is a bad practice.
Try finding an overload in .NET Framework that returns a different type, I cannot think of one.
UPDATE
There are some methods in the .NET Framework as such DateTime.Subtract() but they are the exception and not the rule and only cases where the intention is completely obvious.
我建议这不是最佳实践,因为如果变量声明不是立即可见,它不会产生直观、可读的代码。我通常会使用 GetById 和 GetForFilter、GetAll 等,它们可以更好地描述正在发生的操作。
I would suggest that this is not best practice as it doesnt make for intuitive, readable code if variable declarations are not immediately visible. I would generally use GetById and GetForFilter, GetAll, etc which describes better the action which is taking place.
返回接口是适当的,因为(合理的实践允许)接口会将不同的类链接到类似的问题域并保证一组一致的方法。
然而,不同的类型值得进行气味检查,因为记住可用于获取数据的不同参数比记住返回的各种类型更容易,或者即使您确实记得也必须分支您自己的代码以适应这些类型。
这里没有人提供的缺失替代方案是将两者重载为返回列表,即使 id 只返回一项列表似乎很愚蠢。它对于 jQuery 非常有效,jQuery 相当于一个大规模重载函数的 JavaScript。
一致的回报意味着我只需要记住你的 API 为我做了什么,而不是我必须为它做什么。
Returning interfaces is appropriate since (sound-practices-permitting) an interface is going to link different classes to a similar problem domain and guarantee a consistent set of methods.
Different types, however, deserve a smell-check because it's easier to remember the different args you can use to get at data than it is to remember the various types returned or having to branch your own code to accommodate those types even when you do remember.
The missing alternative that no one's provided here is to overload both as returning a list even if it seems silly for id to only return a one-item list. It's worked great for jQuery which is the JavaScript equivalent of a massively overloaded function.
Consistent returns means I only have to remember what your API does for me rather than what I have to do for it.