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

77%

+5 −0

Q&A When would one not want to return an interface?

I think the main reason to do this is when the interfaces fail to account for some subtlety of the contract between caller and implementation. For example, let's pretend for a moment that your use...

posted 1y ago by matthewsnyder‭ · edited 1y ago by matthewsnyder‭

Answer

#3: Post edited by

matthewsnyder‭ · 2023-06-16T22:10:50Z (over 1 year ago)

Copy Link

Raw

Markdown

I think the main reason to do this is when the interfaces fail to account for some subtlety of the contract between caller and implementation.
For example, let's pretend for a moment that your use case is a performance edge case, and `List` in particular can handle it due to a peculiarity of its implementation, while other implementations catastrophically fail.
In this case, the authors of `List` assumed their performance optimization is a merely an implementation detail and left it out of the interface. However, it has turned out not so. It would take you a lot of time to chase down authors of the standard library and get them to update their interfaces, so you need some way in the meanwhile - you can return the concrete type to tell the callers that it has to be exactly `List` and not just any `IList`. We can further assume the callers are also aware of the performance issue and want to be guaranteed that you avoided it by using `List` and not some other `IList` implementer.
Performance is an easy example because C# interfaces don't explicitly deal with performance expectations. However you can always do things like `IFastList`, `IMyList.MemoryEfficientSort()` or `IMyList.Sort(Int32)` to introduce a sort of performance constraint to the contract.
However, performance is not the only way. For example, there is a `List.Capacity` but not `IList.Capacity`. Normally you shouldn't need to care about capacity, but if your caller happens to have such a need (and simply converting your return value to a new list is not an option) you would have to return `List` not `IList`.
So the critical point here is that you would return concrete types when it turns out that some aspect of the API is germane to the caller-implementation contract, and yet was not included in the interface. That means the interface is now unusable, and you must resort to the concrete type as a short term solution. The long term solution is to create a new interface or update the existing one to fully and parsimoniously describe the contract you are trying to set.
However, I would say that 99% of the time people use the concrete type because they know the concrete type and are more familiar with it than the interface, and it is easier. So it's an antipattern, much like using a single God-object instead of many minimal classes.

I think the main reason to do this is when the interfaces fail to account for some subtlety of the contract between caller and implementation.
For example, let's pretend for a moment that your use case is a performance edge case, and `List` in particular can handle it due to a peculiarity of its implementation, while other implementations catastrophically fail.
In this case, the authors of `List` assumed their performance optimization is a merely an implementation detail and left it out of the interface. However, it has turned out not so. It would take you a lot of time to chase down authors of the standard library and get them to update their interfaces, so you need some way in the meanwhile - you can return the concrete type to tell the callers that it has to be exactly `List` and not just any `IList`. We can further assume the callers are also aware of the performance issue and want to be guaranteed that you avoided it by using `List` and not some other `IList` implementer.
Performance is an easy example because C# interfaces don't explicitly deal with performance expectations. However you can always do things like `IFastList`, `IMyList.MemoryEfficientSort()` or `IMyList.Sort(Int32)` (the `Int32` is `maxSortSeconds`) to introduce a sort of performance constraint to the contract.
However, performance is not the only way. For example, there is a `List.Capacity` but not `IList.Capacity`. Normally you shouldn't need to care about capacity, but if your caller happens to have such a need (and simply converting your return value to a new list is not an option) you would have to return `List` not `IList`.
So the critical point here is that you would return concrete types when it turns out that some aspect of the API is germane to the caller-implementation contract, and yet was not included in the interface. That means the interface is now unusable, and you must resort to the concrete type as a short term solution. The long term solution is to create a new interface or update the existing one to fully and parsimoniously describe the contract you are trying to set.
However, I would say that 99% of the time people use the concrete type because they know the concrete type and are more familiar with it than the interface, and it is easier. So it's an antipattern, much like using a single God-object instead of many minimal classes.

#2: Post edited by

matthewsnyder‭ · 2023-06-14T19:38:12Z (over 1 year ago)

Copy Link

Raw

Markdown

I think the main reason to do this is when the interfaces fail to account for some subtlety of the contract between caller and implementation.
For example, let's pretend for a moment that your use case is a performance edge case, and `List` in particular can handle it due to a peculiarity of its implementation, while other implementations catastrophically fail.
In this case, the authors of `List` assumed their performance optimization is a merely an implementation detail and left it out of the interface. However, it has turned out not so. It would take you a lot of time to chase down authors of the standard library and get them to update their interfaces, so you need some way in the meanwhile - you can return the concrete type to tell the callers that it has to be exactly `List` and not just any `IList`. We can further assume the callers are also aware of the performance issue and want to be guaranteed that you avoided it by using `List` and not some other `IList` implementer.
Performance is an easy example because C# interfaces don't explicitly deal with performance expectations. However you can always do things like `IFastList`, `IMyList.memory_efficient_sort()` or `IMyList.sort(Int32)` to introduce a sort of performance constraint to the contract.
However, performance is not the only way. For example, there is a `List.Capacity` but not `IList.Capacity`. Normally you shouldn't need to care about capacity, but if your caller happens to have such a need (and simply converting your return value to a new list is not an option) you would have to return `List` not `IList`.
So the critical point here is that you would return concrete types when it turns out that some aspect of the API is germane to the caller-implementation contract, and yet was not included in the interface. That means the interface is now unusable, and you must resort to the concrete type as a short term solution. The long term solution is to create a new interface or update the existing one to fully and parsimoniously describe the contract you are trying to set.
However, I would say that 99% of the time people use the concrete type because they know the concrete type and are more familiar with it than the interface, and it is easier. So it's an antipattern, much like using a single God-object instead of many minimal classes.

I think the main reason to do this is when the interfaces fail to account for some subtlety of the contract between caller and implementation.
For example, let's pretend for a moment that your use case is a performance edge case, and `List` in particular can handle it due to a peculiarity of its implementation, while other implementations catastrophically fail.
In this case, the authors of `List` assumed their performance optimization is a merely an implementation detail and left it out of the interface. However, it has turned out not so. It would take you a lot of time to chase down authors of the standard library and get them to update their interfaces, so you need some way in the meanwhile - you can return the concrete type to tell the callers that it has to be exactly `List` and not just any `IList`. We can further assume the callers are also aware of the performance issue and want to be guaranteed that you avoided it by using `List` and not some other `IList` implementer.
Performance is an easy example because C# interfaces don't explicitly deal with performance expectations. However you can always do things like `IFastList`, `IMyList.MemoryEfficientSort()` or `IMyList.Sort(Int32)` to introduce a sort of performance constraint to the contract.
However, performance is not the only way. For example, there is a `List.Capacity` but not `IList.Capacity`. Normally you shouldn't need to care about capacity, but if your caller happens to have such a need (and simply converting your return value to a new list is not an option) you would have to return `List` not `IList`.
So the critical point here is that you would return concrete types when it turns out that some aspect of the API is germane to the caller-implementation contract, and yet was not included in the interface. That means the interface is now unusable, and you must resort to the concrete type as a short term solution. The long term solution is to create a new interface or update the existing one to fully and parsimoniously describe the contract you are trying to set.
However, I would say that 99% of the time people use the concrete type because they know the concrete type and are more familiar with it than the interface, and it is easier. So it's an antipattern, much like using a single God-object instead of many minimal classes.

#1: Initial revision by

matthewsnyder‭ · 2023-06-14T19:37:48Z (over 1 year ago)

Copy Link

Raw

Markdown

I think the main reason to do this is when the interfaces fail to account for some subtlety of the contract between caller and implementation.

For example, let's pretend for a moment that your use case is a performance edge case, and `List` in particular can handle it due to a peculiarity of its implementation, while other implementations catastrophically fail.

In this case, the authors of `List` assumed their performance optimization is a merely an implementation detail and left it out of the interface. However, it has turned out not so. It would take you a lot of time to chase down authors of the standard library and get them to update their interfaces, so you need some way in the meanwhile - you can return the concrete type to tell the callers that it has to be exactly `List` and not just any `IList`. We can further assume the callers are also aware of the performance issue and want to be guaranteed that you avoided it by using `List` and not some other `IList` implementer.

Performance is an easy example because C# interfaces don't explicitly deal with performance expectations. However you can always do things like `IFastList`, `IMyList.memory_efficient_sort()` or `IMyList.sort(Int32)` to introduce a sort of performance constraint to the contract.

However, performance is not the only way. For example, there is a `List.Capacity` but not `IList.Capacity`. Normally you shouldn't need to care about capacity, but if your caller happens to have such a need (and simply converting your return value to a new list is not an option) you would have to return `List` not `IList`.

So the critical point here is that you would return concrete types when it turns out that some aspect of the API is germane to the caller-implementation contract, and yet was not included in the interface. That means the interface is now unusable, and you must resort to the concrete type as a short term solution. The long term solution is to create a new interface or update the existing one to fully and parsimoniously describe the contract you are trying to set.

However, I would say that 99% of the time people use the concrete type because they know the concrete type and are more familiar with it than the interface, and it is easier. So it's an antipattern, much like using a single God-object instead of many minimal classes.

Communities

Post History