Re: Return collection interfaces or collection objects???

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]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx

"Veloz" <michaelveloz@xxxxxxxxx> wrote in message
news:1190566575.144904.109520@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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



.

Relevant Pages

  • Return collection interfaces or collection objects???
    ... appropriate interface of the object, ... Create sone specific collection instance, ... dependancy - the caller will be returned an object reference and will ... routine would need to provide (in our case, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How do I use a TOleServer derived object properly? (Yet another interface question).
    ... I think you're ok with using the object as an object reference, ... By the way, when you imported the TLB, did you tell it to support events? ... > TConnection = class ... > look like they're intended to implement the _IConnectionEvents interface ...
    (borland.public.delphi.language.objectpascal)
  • Re: Interface as Object. can I do this?
    ... Because of interface reference counting using an object reference is ... I don't think that technique is "nasty hacking". ...
    (borland.public.delphi.language.objectpascal)
  • Re: dynamic runtime casting?
    ... dynamic_cast is identical to the VB TryCast function - they both compile to ... interface on an object by name. ... All you have is a univeral object reference ...
    (microsoft.public.dotnet.languages.vc)
  • How do interface implementations work?
    ... When a class implements an interface, how can it access its fields from ... Normally, when you call a method on an object reference, the object ... reference gets passed in the EAX register, ...
    (borland.public.delphi.language.objectpascal)