I want to write code that is decouple and clean, and I know that by programming to an interface instead of the implementation, my code will be more flexible and extensible. So, instead of writing methods like:

  bool IsProductAvailable(ProductTypeA product);

I write methods like:

  bool IsProductAvailable(IProduct product);

As long as my products implement IProduct:

  class ProductTypeA : IProduct

I should be OK. All is well until I start using generic collections. Since C# 3.0 doesn't support covariant and contravariant, even though both ProuctTypeA and ProductTypeB implements IProduct, you cannot put List in List. This is pretty troublesome because a lot of times I want to write something like:

bool AreProductsAvailable(List<IProduct> products);

So that I can check product avaialbility by writing:

List<ProductA> productsArrived = GetDataFromDataabase();
bool result = AreProductsAvailable(productsArrived);

And I want to write just one AreProductsAvailable() method that works with all IProduct collections.

I know that C# 4.0 is going to support covariant and contravariant, but I also realize that there other libraries that seemed to have the problem solved. For instance, I was trying out ILOG Gantt the gantt chart control, and found that they have a lot of collection intefaces that looks like this:

IActivityCollection
ILinkCollection

So it seems like their approach is wrapping the generic collection with an interface. So instead of "bool AreProductsAvailable(List products);", I can do:

bool AreProductsAvailable(IProductCollection products);

And then write some code so that IProductCollection takes whatever generic collection of IProduct, be it List or List.

However, I don't know how to write an IProductCollection interface that does that "magic". :-< (ashame) ....

Could someone shed me some light? This has been bugging me for so long, and I so wanted to do the "right thing". Well, thanks!