My guidelines has always been most specific out, and most general in.
The more general your data type is, the less the code that uses it knows about the data type. For instance, if a method returns a collection, I would return the newly created collection that the method produced. If it returns an internal data structure, I would bump it up to IEnumerable<T>.
However, if it returns an array, or a List<T> because that's what it built internally, the code that gets hold of your data now has access to more functionality on your collection.
The other end of the spectrum, to return the most general (within limits) data type would mean that you always return IEnumerable<T> or similar for all collections, even if the method built a new array internally and returned that. The calling code now has to manually copy the contents of the collection into a new array or list, if that is what the calling code needs to use.
This means more, and in most cases, unnecessary work.
As for input, I go for the most general type I can use, so for collections, unless I specifically need an array or a list or similar, I will accept IEnumerable<T>. By doing so, I ensure that calling code has less work to do. This might mean that I have to do some work internally, so it's a trade-off.
The important part is to reach a balance. Don't be too general or too specific, all the time, every time. Figure out the right type that makes sense and consider what the calling code has to do in order to pass data in or accept outgoing data from your code. The less work, the better.
In general I would go for the more general type. That way I won't break any client that may use the information about the return type.
If I return a more general type, in the implementation of the action method I can always change the type to something different. Consider the following scenario: You return a custom action result that derives from ActionResult. Somewhere in your code base something makes an assumption that the return value is MyCustomActionResult. In that case if you changed the return value you would break the client code.
BTW: I do the same - returning the most appropriate general type - for all methods not only for action methods.
Edit: Please note that this doesn't mean that I'd return object. The challenge is to find the type that represents the "most appropriate" abstraction.
发布评论
评论（2）
我的指南始终是最具体的，也是最通用的。
数据类型越通用，使用它的代码对数据类型的了解就越少。例如，如果一个方法返回一个集合，我将返回该方法生成的新创建的集合。如果它返回内部数据结构，我会将其提升为 IEnumerable。
但是，如果它返回一个数组或
List（因为这是它内部构建的），则获取数据的代码现在可以访问集合上的更多功能。另一方面，返回最通用（在限制内）的数据类型意味着您始终返回
IEnumerable或所有集合的类似数据类型，即使该方法在内部构建了一个新数组并返回。调用代码现在必须手动将集合的内容复制到新的数组或列表中（如果调用代码需要使用的话）。这意味着更多且在大多数情况下是不必要的工作。
至于输入，我选择可以使用的最通用的类型，因此对于集合，除非我特别需要数组或列表或类似的类型，否则我将接受
IEnumerable。通过这样做，我确保调用代码需要做的工作更少。这可能意味着我必须在内部做一些工作，所以这是一个权衡。重要的是达到平衡。始终、每次都不要太笼统或太具体。找出有意义的正确类型，并考虑调用代码必须执行哪些操作才能将数据传入或接受代码中的传出数据。工作越少越好。
My guidelines has always been most specific out, and most general in.
The more general your data type is, the less the code that uses it knows about the data type. For instance, if a method returns a collection, I would return the newly created collection that the method produced. If it returns an internal data structure, I would bump it up to
IEnumerable<T>.However, if it returns an array, or a
List<T>because that's what it built internally, the code that gets hold of your data now has access to more functionality on your collection.The other end of the spectrum, to return the most general (within limits) data type would mean that you always return
IEnumerable<T>or similar for all collections, even if the method built a new array internally and returned that. The calling code now has to manually copy the contents of the collection into a new array or list, if that is what the calling code needs to use.This means more, and in most cases, unnecessary work.
As for input, I go for the most general type I can use, so for collections, unless I specifically need an array or a list or similar, I will accept
IEnumerable<T>. By doing so, I ensure that calling code has less work to do. This might mean that I have to do some work internally, so it's a trade-off.The important part is to reach a balance. Don't be too general or too specific, all the time, every time. Figure out the right type that makes sense and consider what the calling code has to do in order to pass data in or accept outgoing data from your code. The less work, the better.
一般来说，我会选择更通用的类型。这样我就不会破坏任何可能使用有关返回类型的信息的客户端。
如果我返回一个更通用的类型，在操作方法的实现中我总是可以将类型更改为不同的类型。考虑以下场景：您返回派生自
ActionResult的自定义操作结果。在您的代码库中的某个地方，假设返回值为MyCustomActionResult。在这种情况下，如果您更改返回值，则会破坏客户端代码。顺便说一句：我也做了同样的事情 - 返回最合适的通用类型 - 对于所有方法，而不仅仅是操作方法。
编辑：请注意，这并不意味着我会返回
对象。挑战在于找到代表“最合适”抽象的类型。In general I would go for the more general type. That way I won't break any client that may use the information about the return type.
If I return a more general type, in the implementation of the action method I can always change the type to something different. Consider the following scenario: You return a custom action result that derives from
ActionResult. Somewhere in your code base something makes an assumption that the return value isMyCustomActionResult. In that case if you changed the return value you would break the client code.BTW: I do the same - returning the most appropriate general type - for all methods not only for action methods.
Edit: Please note that this doesn't mean that I'd return
object. The challenge is to find the type that represents the "most appropriate" abstraction.