Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
IList<T> is not necessarily representative of the general case; it's an interface that is (A) widely implemented by a variety of classes from a variety of sources, which themselves (B) tend t...
Answer
#2: Post edited
by
r~~
·
2023-01-09T16:37:35Z (over 1 year ago)
`IList<T>` is not necessarily representative of the general case; it's an interface that is (A) widely implemented by a variety of classes from a variety of sources, which themselves (B) tend to add additional functionality or constraints not captured by the signature of `IList<T>`. There is, in my opinion, very little if any reason to ever return a `List<T>` instead of an `IList<T>`, but you could very well want to return a `SortedSet<T>` in order to get at its `Min` and `Max` properties.- Ideally, for that example, there'd be some sort of `ISortedSet<T>` interface that would abstract over those properties. But there isn't, as of .NET 7.0, which historically is representative of the story with these abstract collection interfaces. Good ideas, 80% execution. So in practice, sometimes you want to type things concretely.
- For interfaces that don't get around as much, like ye olde `IMyInternalApplicationService`, you won't go wrong always favoring those over their concrete implementations everywhere in your code except the place where you tie off your dependency injection knots.
- `IList<T>` is not necessarily representative of the general case; it's an interface that is (A) widely implemented by a variety of classes from a variety of sources, which themselves (B) tend to add additional functionality or constraints not captured by the signature of `IList<T>`. There is, in my opinion, very little <s>if any</s> [see below for one] reason to ever return a `List<T>` instead of an `IList<T>`, but you could very well want to return a `SortedSet<T>` in order to get at its `Min` and `Max` properties.
- Ideally, for that example, there'd be some sort of `ISortedSet<T>` interface that would abstract over those properties. But there isn't, as of .NET 7.0, which historically is representative of the story with these abstract collection interfaces. Good ideas, 80% execution. So in practice, sometimes you want to type things concretely.
- ---
- Peter Taylor adds: ‘Another issue specific to `IList<T>` is that for legacy reasons it doesn't inherit from `IReadOnlyList<T>`. Returning `List<T>` allows callers to assign to `IReadOnlyList<T>`, which can make it easier to reason about the calling code.’
- ---
- For interfaces that don't get around as much, like ye olde `IMyInternalApplicationService`, you won't go wrong always favoring those over their concrete implementations everywhere in your code except the place where you tie off your dependency injection knots.
#1: Initial revision
by
r~~
·
2022-12-22T00:09:38Z (over 1 year ago)
`IList<T>` is not necessarily representative of the general case; it's an interface that is (A) widely implemented by a variety of classes from a variety of sources, which themselves (B) tend to add additional functionality or constraints not captured by the signature of `IList<T>`. There is, in my opinion, very little if any reason to ever return a `List<T>` instead of an `IList<T>`, but you could very well want to return a `SortedSet<T>` in order to get at its `Min` and `Max` properties. Ideally, for that example, there'd be some sort of `ISortedSet<T>` interface that would abstract over those properties. But there isn't, as of .NET 7.0, which historically is representative of the story with these abstract collection interfaces. Good ideas, 80% execution. So in practice, sometimes you want to type things concretely. For interfaces that don't get around as much, like ye olde `IMyInternalApplicationService`, you won't go wrong always favoring those over their concrete implementations everywhere in your code except the place where you tie off your dependency injection knots.