Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

.NET Framework built-in interfaces, recommendations when building a custom data structure?

I'm implementing an AVL binary tree data structure in C# .NET 2.0 (possibly moving to 3.5). I've got it to the point where it is passing my initial unit tests without needing to implement any framework level interfaces.

But now, just looking through the FCL I see a whole bunch of interfaces, both non-generic and generic that I could implement to ensure my class plays nicely with language features and other data structures.

At the moment the only obvious choice (to me at least) is one of the Enumeration style interfaces to allow a caller to use the tree in a foreach loop and possibly with Linq later on. But which one (or more)?

Here are the interfaces I'm considering at present:

  • IEnumerable and IEnumerable<T>
  • IEnumerator and IEnumerator<T>
  • IComparable and IComparable<T>
  • IComparer and IComparer<T>
  • ICollection and ICollection<T>
  • IEquatable and IEquatable<T>
  • IEqualityComparer and IEqualityComparer<T>
  • ICloneable
  • IConvertible

Are there any published guidelines, either online or in book form, that provide recommendations regarding which framework interfaces to implement and when?

Obviously for some interfaces, if you don't want to provide that functionality, just don't implement the entire interface. But it appears there are certain conventions in the FCL classes (such as Collection classes) that perhaps we should also follow when building custom data structures.

Ideally the recommendations would provide guidance on such questions as when to use IComparer or IEqualityComparer, IEnumerable or IEnumerator? Or, if you implement a generic interface, should you also implement the non-geneic interface? etc..

Alternatively, if you have guidance to offer based on your own experiences, that would be equally useful.

like image 771
Ash Avatar asked Dec 06 '25 18:12

Ash


1 Answers

You should be aware that some of those interfaces inherit from each other (ICollection<T> and IEnumberable<T>) and the generic versions of interfaces generally require the implententation their non-generic versions. IEnumerator and IEnumerable are connected (an IEnumerable traditionally creates an IEnumerator to do the enumeration)

Implementing IComparable<T> is on a collection is fraught with danger (are you comparing the members in the collection?), and IComparer<T> is a helper interface for sorting methods.

ICloneable is a bit outdated - but it's meant to enable creating a deep copy (which, again, is fraught with danger for a collection.

I'd take issue with your

Obviously for some interfaces, if you don't want to provide that functionality, just don't implement them.

If you implement an interface, you should implement all the members of it. (see Liskov Substitution Principle)

Implementing IConvertible for a collection also seems strange - you might perfer to implement ISerializable.

The MSDN Documentation for the interfaces is a bit terse, but you can always google them to see how they work.

like image 86
kͩeͣmͮpͥ ͩ Avatar answered Dec 08 '25 10:12

kͩeͣmͮpͥ ͩ



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!