Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / September 2007

Tip: Looking for answers? Try searching our database.

Return collection interfaces or collection objects???

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Veloz - 23 Sep 2007 17:56 GMT
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] - 24 Sep 2007 18:23 GMT
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).

Signature

         - Nicholas Paldino [.NET/C# MVP]
         - mvp@spam.guard.caspershouse.com

> Hi there
>
[quoted text clipped - 36 lines]
>
> Michael
Doug Semler - 24 Sep 2007 18:59 GMT
On Sep 24, 1:23 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com> wrote:
> Veloz,
>
[quoted text clipped - 57 lines]
>
> > 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)

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.