System.Collections.DictionaryBase

While CollectionBase allows us to implement strongly-typed collections of objects, another
class called
DictionaryBase
provides the abstract base class for creating
strongly-typed collections of (key, value) pairs. Just as CollectionBase encapsulates an
ArrayList, DictionaryBase encapsulates a Hashtable and provides access
to it via a protected property called InnerHashtable. DictionaryBase also contains
a protected property called Dictionary, which is nothing but DictionaryBase
itself returned as an IDictionary (notice that DictionaryBase implements
IDictionary). The semantics of defining explicit interface member implementations are the same
as in the previous case, which means that even though certain methods like Add and Remove
are defined in DictionaryBase, they can only be accessed via an instance of IDictionary.

The following is a type-safe hashtable that stores int/Customer pairs as opposed to
object/object pairs stored in a Hashtable. All calls to
CustomerTable are delegated to the Dictionary object--they could be delegated to the InnerHashtable object as well.

CollectionBase and DictionaryBase solve the problem more elegantly than the
first approach. They take most of the work out of implementing a type-safe collection. However, they
suffer from some drawbacks that we did not see in the first approach:

Since CustomerList is not of type ArrayList, we cannot pass a
CustomerList wherever an ArrayList is expected. We could provide a method
that returns the InnerList object, but that would violate the rules of encapsulation.

If we want type-safe versions of more specialized collections like Stack and
Queue, we're out of luck using this approach.

Third Approach: Containing Existing Collection Classes

Even though the above approach works well for most collection classes, it does not address creation of
type-safe Stack and Queue classes. To implement these, we could either use the
inheritance method we saw in the first approach, or we could use the
containment/delegation method (similar to the second approach, except that this time we do it independent
of CollectionBase). The following class creates a type-safe Stack
of Customer objects using containment and delegation.

This approach gives us more flexibility in implementing our collections. For example, we could use the
same class to implement multiple collections. Also, containment protects us from any future changes
to the collections classes. The downside of this approach is the same as we saw with the second
approach--since CustomerStack is not of type Stack,
it cannot be passed wherever a Stack is expected.

In the above code, we could make CustomerStack implement the ICollection interface,
but in that case, we must be prepared to provide implementations for all of the methods and properties of
ICollection. By not implementing ICollection, we just chose a little freedom
for ourselves so that we could provide only the minimum functionality required for our stack implementation,
while still leveraging the contained Stack object by delegating all calls to it.

Conclusion

Even though all of the above approaches achieve compile-time type safety, none of them is
particularly elegant or efficient, for the following reasons:

All of them require us to write every type of collection for every type of object we wish to
store. This sacrifices polymorphism and results in code duplication.
The size of an application that wishes to achieve such
precise type safety can increase rapidly, and fixing bugs in the duplicated sections can be quite a task.

Since collection classes in C# are designed with reference types in mind, using them with value types
leads to unnecessary boxing
and
unboxing,
which degrades performance. All three approaches discussed in this article make use of the built-in collection classes,
so they all suffer from the same performance problem.

The problems faced by the Collections Framework are precisely the problems that generic types
try to solve, but until we see support for generics in C#, we will have to either implement our own
type-safe collections, or succumb to writing type-unsafe code that rears its ugly head during a demo.

Amit Goel
has been developing object-oriented
applications for several years. You can learn more about him at www.amitgoel.com.