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!