I have a method which selects a distinct collection of objects, adds them to a list and then returns the list.
Initially the method returned IEnumerable but as it returns a distinct collection I could add the distinct objects to a hashset and return ISet instead.
I appreciate that ISet makes the returned object modifiable (consumers could Add() to it) but I’m returning a new list anyway so I don’t think this affects me, as why do I care what the consumers do with the collection once they have it?
The question is, should I do this? Or should I just return IEnumerable and be happy that it only contains distinct elements (which is currently guaranteed by a test)
As ever, with design, you have contradictory requirements at play here. The art of good design is choosing the best balance between these requirements for the product you are creating.
One principal of interface design is that you consider the interface to be a contract or promise. Its obvious that, the less prescriptive a promise or contract is, the easier it is to keep. So, a return type of
IEnumerable<T>means you are promising to return only a sequence of things. A “thighter” or more derived type would be more prescriptive and, a harder promise to keep.Reflectively, if you are doing work in your function to ensure that a return type is more dervied, then it seems wasteful to abandon that work by returning the less perscriptive parent type. If you already have an
ISet<T>, defining a set of things, be explicit, return that and save the caller the work of the distinct check.In general, there is no simple answer, the right answer depends on the caller and your system. We have no knowledge of the caller in the general case. In the absence of evidence, we must assume nothing and take the tangible benefit of the weaker promise. So, in general, go with
IEnumerable<T>it gives you greater flexibility in the furture with no known cost now.In the specific case, where we know the caller will benefit from the return of a set. This is you case where a bug is raised on the distinctness of the sequence. It makes sense to be explicit and return an
ISet<T>, this will help prevent duplication of the distinct check. To add a caveat, this only makes sense if the data will be distinct for every possible call. You must ensure you will keep the promise for all callers, not just those who have raised the bug.