两者的好处或坏处是什么?
2 回答
我的指导方针一直是最具体的,也是最笼统的。
您的数据类型越通用,使用它的代码对数据类型的了解就越少。例如,如果一个方法返回一个集合,我将返回该方法生成的新创建的集合。如果它返回一个内部数据结构,我会把它提高到IEnumerable<T>
.
但是,如果它返回一个数组,或者List<T>
因为它是内部构建的,那么获取您的数据的代码现在可以访问您的集合上的更多功能。
另一方面,返回最通用(在限制范围内)的数据类型意味着您总是IEnumerable<T>
为所有集合返回或类似的,即使该方法在内部构建了一个新数组并返回它。调用代码现在必须手动将集合的内容复制到新的数组或列表中,如果这是调用代码需要使用的。
这意味着更多,在大多数情况下,是不必要的工作。
至于输入,我选择我可以使用的最通用的类型,所以对于集合,除非我特别需要一个数组或列表或类似的,我会接受IEnumerable<T>
. 通过这样做,我确保调用代码有更少的工作要做。这可能意味着我必须在内部做一些工作,所以这是一个权衡。
重要的部分是达到平衡。不要太笼统或太具体,一直,每次。找出有意义的正确类型,并考虑调用代码必须执行哪些操作才能将数据传入或接受来自代码的传出数据。工作越少越好。
一般来说,我会选择更通用的类型。这样我就不会破坏任何可能使用返回类型信息的客户端。
如果我返回更通用的类型,在操作方法的实现中,我总是可以将类型更改为不同的类型。考虑以下场景:您返回一个自定义操作结果,它派生自ActionResult
. 在您的代码库中的某处,假设返回值为MyCustomActionResult
. 在这种情况下,如果您更改了返回值,您将破坏客户端代码。
顺便说一句:我做同样的事情 - 返回最合适的通用类型 - 不仅适用于操作方法,而且适用于所有方法。
编辑:请注意,这并不意味着我会返回object
. 挑战在于找到代表“最合适”抽象的类型。