tags:

views:

165

answers:

6

Hi,

In my BL (will be a public API), I am using ICollection as the return types in my Find methods, like:

public static ICollection<Customer> FindCustomers()
{
   Collection<Customer> customers = DAL.GetCustomers();

   return customers;
}

Note the use of ICollection instead of Collection<>.

Now in my GUI, I need to cast the results back to Collection, like:

Collection<Customer> customers = (Collection<Customer>)BL.FindCustomers();

This is because I need to use some Collection<> specific methods on my returned list, which I cannot do with ICollection<>.

Is this the correct usage? Or should I simply change the return type from Collection<> instead to ICollection<> in order to avoid this casting?

Secondly, I did not use IEnumerable because it is more generic than ICollection and does not even have simple properties like Count. And I really don’t see a point in generalizing the return types here. Am I missing something important?

A: 

The idea of returning ICollection is so that you have less coupling on your method. If you want to build a List later, instead a Collection, you'll be able to do it without breaking client code and so on.

If you're using this just to get a Collection (and not an ICollection), than IMHO you could change to Collection, knowing you'll have a less flexible method. But anyway, YAGNI.

Additionally, if you're worrying about design, I'd suggest not making this static, to improve the testability of your code.

Samuel Carrijo
A: 

That's probably because Collection implements IList which has some extra methods that ICollection hasn't, is IList enough for you. What methods are you missing?

Ariel Popovsky
+2  A: 

The whole point of using ICollection is to be more generic and hide more information, which is a good thing.

But if you need to convert it back it has become pointless and you might as well return the more functional Collection< > instead.

Henk Holterman
A: 

If you're going to require your users to use methods of Collection<>, you should probably return Collection<> rather than ICollection.

Or maybe use have separate function that is internal to your assembly that returns the type you need for your GUI:

internal static ICollection<Customer> FindCustomers()
{
    Collection<Customer> customers = DAL.GetCustomers();

    return customers;
}
Valentein
+2  A: 

The only reason you would want to return ICollection is for loose coupling and inheritance purpouses. If there is only 1 version of your method (which there is becaue its static) youll always know the return type (Collection) and there is no need to make it an ICollection. However if you were using in a family of classes, there could be a virtual or abstract method that return and ICollection, then in the subclass implementations one can return a Collection or a FunkyCollection or any object that implements the interface, so this gives you a lot more f lexibility that saying you can only return a Collection. But for your purposes you should prolly just make the return type Collection and not ICollection because its a static method that wont be overriden. Also it causes less confusion to the user because they dont need to cast.

Daniel
A: 

Everyone else has already given such great answers, but I just wanted to clarify that no, I don't believe what you are doing is ideal. The reasons for this is that if someone comes along later and modifies/refactors/reimplements your BL to return some other type of ICollection (as per the API) that is not really a Collection, you will get runtime errors in your GUI.

You could, however, still choose to return an ICollection from your BL: Then, if you really wanted a Collection (probably, for one or more of its convenient extension methods, I'm guessing?), then you could create a new collection and copy the contents from one to the other. This way, you're not risking the runtime error. Although, it ultimately depends (as someone else already asked) on which method(s) you're looking for in the Collection... Perhaps there is a better way to do what you want.

Good luck!
-f!

Funka