Return collection interfaces or collection objects???
- From: Veloz <michaelveloz@xxxxxxxxx>
- Date: Sun, 23 Sep 2007 09:56:15 -0700
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
.
- Follow-Ups:
- Re: Return collection interfaces or collection objects???
- From: Nicholas Paldino [.NET/C# MVP]
- Re: Return collection interfaces or collection objects???
- Prev by Date: thread sleep
- Next by Date: Re: Can Dictionary<> store a static class ref?
- Previous by thread: thread sleep
- Next by thread: Re: Return collection interfaces or collection objects???
- Index(es):
Relevant Pages
|
