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!
