Return collection interfaces or collection objects???

[Veloz]

Hi there

My question is regarding how to best return "collections" from a
method call. Should you return an actual object or an interesting/
appropriate interface of the object, to the caller? (This is not
really restricted to returning collections but that's the example I'm
going to focus on)

For example, let's say you have method that is going to return a "list
of books".

Seems like you have at least these two options:

1. Create sone specific collection instance, like List<Book> and
return it.
2. Create sone specific collection instance, like List<Book> but
return it as an IList interface

Which is generally "better"?

It seems like returning the object reference means you have set up a
dependancy - the caller will be returned an object reference and will
likely write code to depend on that object's type, meaning that if you
have to change the storage type later, you may have a lot of hunt-and-
fix operations on your hand.

This would suggest that returning an interface would be better. The
caller would still have the minimum functionality that the called
routine would need to provide (in our case, a way iterate over the
list and get items out of it) .. and the called routine could actually
instantiate some different object later as long as it also supports
IList. The caller would not know.

On the other hand, it seems like if you create a rich, highly
functional collection, it would be nice for the client to be able to
use all its features..

Any thoughts on this???

Michael

 

[Nicholas Paldino [.NET/C# MVP]]

Veloz,

Personally, I like returning an interface (IList<T>) better than
List<T>. I like this as a general rule, and not just for collections. If
you return an interface, you have a number of options in terms of
implementation (from changing the implementation, to swapping it outright if
you want to) which you don't have with returning concrete implementations.

For IList<T>/List<T> implementations, there isn't anything that List<T>
implements over IList<T> which is absolutely essential. If you need some of
those other operations, you can return List<T>, but you have to remember
that you are possibly returning a reference to the internal implementation,
and you are exposing operations on that reference (which IList does as well,
but a little more so with the concrete implementation).

And remember, you can always take the elements in the IList<T>
implementation and put them in a new List<T> implementation (through the
constructor, which takes an IEnumerable<T> instance, which IList<T> is).

 

[Doug Semler]

Veloz,

Personally, I like returning an interface (IList<T>) better than
List<T>. I like this as a general rule, and not just for collections. If
you return an interface, you have a number of options in terms of
implementation (from changing the implementation, to swapping it outright if
you want to) which you don't have with returning concrete implementations.

For IList<T>/List<T> implementations, there isn't anything that List<T>
implements over IList<T> which is absolutely essential. If you need some of
those other operations, you can return List<T>, but you have to remember
that you are possibly returning a reference to the internal implementation,
and you are exposing operations on that reference (which IList does as well,
but a little more so with the concrete implementation).

And remember, you can always take the elements in the IList<T>
implementation and put them in a new List<T> implementation (through the
constructor, which takes an IEnumerable<T> instance, which IList<T> is).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi there

My question is regarding how to best return "collections" from a
method call. Should you return an actual object or an interesting/
appropriate interface of the object, to the caller? (This is not
really restricted to returning collections but that's the example I'm
going to focus on)

For example, let's say you have method that is going to return a "list
of books".

Seems like you have at least these two options:

1. Create sone specific collection instance, like List<Book> and
return it.
2. Create sone specific collection instance, like List<Book> but
return it as an IList interface

Which is generally "better"?

It seems like returning the object reference means you have set up a
dependancy - the caller will be returned an object reference and will
likely write code to depend on that object's type, meaning that if you
have to change the storage type later, you may have a lot of hunt-and-
fix operations on your hand.

This would suggest that returning an interface would be better. The
caller would still have the minimum functionality that the called
routine would need to provide (in our case, a way iterate over the
list and get items out of it) .. and the called routine could actually
instantiate some different object later as long as it also supports
IList. The caller would not know.

On the other hand, it seems like if you create a rich, highly
functional collection, it would be nice for the client to be able to
use all its features..

Any thoughts on this???

About the only caveat I have to Nicholas' statement is when you need
to serialize the function result (e.g., a web service or remoting
call) you're going to want to use a concrete class instantiation (I
prefer Collection<T>, it hides pretty much all of the implementation
details)