C# in Depth

46 CHAPTER 2 Core foundations: building on C# 1a string array, and will reject attempts to store references to nonstrings. Covariance isoften useful, but comes at the cost of some of the type safety being implemented atexecution time instead of compile time.Let’s compare this with the situation that the weakly typed collections such as Array-List and Hashtable put us in. The API of these collections uses object as the type ofkeys and values. When you are writing a method that takes an ArrayList, for example,there is no way of making sure at compile time that the caller will pass in a list of strings.You can document it, and the type safety of the runtime will enforce it if you cast eachelement of the list to string, but you don’t get compile-time type safety. Likewise, if youreturn an ArrayList, you can indicate in the documentation that it will just containstrings, but callers will have to trust that you’re telling the truth, and will have to insertcasts when they access the elements of the list.Finally, consider the strongly typed collections such as StringCollection. Theseprovide an API that is strongly typed, so you can be confident that when you receivea StringCollection as a parameter or return value it will only contain strings, andyou don’t need to cast when fetching elements of the collection. It sounds ideal, butthere are two problems. First, it implements IList, so you can still try to add nonstringsto it (although you’ll fail at runtime). Second, it only deals with strings.There are other specialized collections, but all told they don’t cover much ground.There’s the CollectionBase type, which can be used to build your own stronglytyped collections, but that means creating a new collection type for each elementtype, which is also not ideal.Now that we’ve seen the problem with collections, let’s consider the issue that canoccur when overriding methods and implementing interfaces. It’s related to the ideaof covariance, which we’ve already seen with arrays.LACK OF COVARIANT RETURN TYPESICloneable is one of the simplest interfaces in the framework. It has a single method,Clone, which should return a copy of the object that the method is called on. Now,leaving aside the issue of whether this should be a deep or shallow copy, let’s look atthe signature of the Clone method:object Clone()It’s a straightforward signature, certainly—but as I said, the method should return acopy of the object it’s called on. That means it needs to return an object of the sametype—or at least a compatible one (where that meaning will vary depending on thetype). It would make sense to be able to override the method with a signature that givesa more accurate description of what the method actually returns. For example, in aPerson class it would be nice to be able to implement ICloneable withpublic Person Clone()That wouldn’t break anything—code expecting any old object would still work fine. Thisfeature is called return type covariance but unfortunately, interface implementation andmethod overriding don’t support it. Instead, the normal workaround for interfaces isto use explicit interface implementation to achieve the desired effect:Licensed to Rhona Hadida