Peter Golde's Blog : Helper base classes

Wednesday, September 22, 2004 2:51 PM pgolde

Helper base classes

There are currently two “helper base classes” in Power Collections, CollectionBase and DictionaryBase. These classes are there because there was a lot of boilerplate code involved in implementing the various collection interfaces, ICollection<T>, ICollection, IDictionary<T>, and IDictionary. This code begged to be put into some common base classes.

Although they served my purposes OK, they weren't very easy to use. The biggest problem was that I tried to have a single base class work for both read-only and read-write version of the collections. Making a single class work for both cases, in the end, produced a compromise that made the base classes difficult to use. The read-only class really needs to implement the modification methods with explicit interface implementation that throw NotImplementExceptions. The read-write class really should have abstract methods to force the derived class to implement them.

So in the interests of making these classes more broadly useful, I split them into ReadOnlyCollectionBase and CollectionBase, and ReadOnlyDictionaryBase and DictionaryBase. I also created ReadOnlyListBase and ListBase that do the same thing for IList and IList<T>. Although splitting the classes into read-only and read-write variants made a lot of sense, the big drawback seemed to be cluttering up the namespace. I now had six classes that were really only of interest to people writing their own collections, are are useless to the 98% of people who are just looking for a collection to use. So I put these classes into new sub-namespace: Wintellect.PowerCollections.BaseClasses. This keeps them out of the way for people browsing the documentation looking for the right class to use.

Comments?

Filed under: Peter Golde

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

#

Wednesday, September 22, 2004 4:30 PM by Nils Jonsson

This is a thorny issue, and I imagine I might have decided to do the same in your shoes, but it’s worth mentioning that this violates the .NET convention that speaks to dependencies among namespaces: “A nested namespace should have a dependency on types in the containing namespace. For example, the classes in System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design.” (<a target="_new" href="http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnamespacenamingguidelines.asp">http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnamespacenamingguidelines.asp</a>)

#

Wednesday, September 22, 2004 5:09 PM by Michael Teper

I understand the motivation, bit I also agree, this is inappropriate nesting.

#

Wednesday, September 22, 2004 11:21 PM by Martin Plante

If splitting the classes is meant to simplify things, I believe you should also keep them in the same namespace, for the same reason. Having their name end with "Base" is enough for me, and should suit 95% of those 98% just looking for a collection to use. It doesn't make sense to put them in a separate namespace.

#

Wednesday, September 22, 2004 11:23 PM by Matthew W. Jackson

That guideline isn't entirely clear....

Does "dependency" mean a type having public members of another type? Does it mean deriving from a type? Does it include implementing an interface from another namespace? Does it include using a type in private implementation?

The first is violated by every implementation of GetEnumerator (granted, that's just an interface). It's also violated by System.Type.Assembly. (System.Type could arguably have been put in System.Reflection, but then that would cause a problem with System.Object.GetType(), wouldn't it?)

The second case is what is being questioned here. I can't think of an example in the framework that directly violates this (but that does not mean it doesn't exist), so I'll come back to this...

The third is violated all over the place. Many implementations of IComparable, IEnumerable, IList, etc. break this rule. I'm guessing that interfaces don't really count as dependencies, since you aren't depending on anything in the interface other than a contract. This is why implementing a generic interface is still CLS-Compliant. You aren't dependant on the consumer supporting generics.

I don't think the fourth applies at all, in any case. There are several cases of this, and it often cannot be avoided (nor would you want to avoid it). System.String.Format uses System.Text.StringBuilder, for example. There are countless others.

Which brings me back to #2...inheritance. The collections are inheriting from a type in a nested namespace. The collections do _technically_ depend on the types. However, when coding against the collections, you do not ever need to acknowledge the existance of these base types or the namespace they are in. They could easily be internal base classes in a namespace unseen to consumers, but since they could be useful, they should remain public.

I think the guideline exists so that when you are working with a type in a namespace, and you come across a property or parameter, you don't have to dig to find types in a nested namespace. So if you were coding a class, and had a "using Wintellect.PowerCollections", you won't have to type "Wintellect.PowerCollections.BaseClasses" (or add another using statement) just because a method depended on a type in that namespace. This is due to the way the imports/using works. If you could refer to the types by simply "BaseClasses", this wouldn't be an issue at all, really.

However, in this case, you will _never_ need anything in Wintellect.PowerCollections.BaseClasses. You will never code against the Wintellect.PowerCollections.BaseClasses types, unless you are extending a type for a custom collection. So the user of the library does not need to pay any regard to this namespace at all. The guideline is, by definition, not a rule. An exception to the guideline is perfectly acceptable in this case because it remains true to the spirit of and reasoning behind the guideline.

Also, I think the guideline needs to be revised to explain "dependency".

#

Wednesday, September 22, 2004 11:25 PM by Matthew W. Jackson

Oh, and I just realized that they couldn't be "internal" due to visibility rules of inheritance, but they could have internal constructors which would effectively make them internal.

#

Thursday, April 14, 2005 8:42 AM by David Taylor

Hello Peter,

I am looking at MultiDictionaryBase, which is derived from CollectionBase, and I'd like to know why MultiDictionaryBase maps a TKey to an IEnumerable<TValue>, rather than to a ICollection<TValue>.

Over the past year, I have created many 'power collections' of my own in my application, but I intend to change over to your library after Whidbey Beta 2 arrives. My equivalent to MultiDictionary uses ICollection<TValue> since I often need to know the how many values there are for a given key.

Since you store the value count in your KeyAndValues struct, you could easily use ICollection<TValue> instead of IEnumerable<TValue>.

Was there a reason for this design decision?

#

Wednesday, April 20, 2005 2:13 PM by Peter Golde

After thinking about it, using ICollection<TValue> seems to have a bunch of advantages. I'd have to experiment further to see if there are any problems that develop with that, but it seems pretty promising, and it allows some nicer idioms:

dict[key].Add(...)

dict[key].Count

dict[key].Remove

dict[key].Clear

Name (required)
Your URL (optional)
Comments (required)

Please enter the answer to the math question here: (required)
Remember Me?

Search

Tags

Navigation

Archives