I (am just a developer) am tasked with training my team on a technique or technology. I zeroed upon System Interfaces, IComparable and IEquatable to be specific. How does one go about teaching (even if it is 1 hour), what an IComparable is and where we can use it by giving them an example.

However, I am not entirely sure whether that would make my team to understand and start using IComparable.

In my project, however, I do have a Discount class and there are instances where I have to merge two lists of Discounts. Now, that would be a really good instance of where IEquatable would be helpful when I do the merge wouldn't it?

I had the following template for training.

  • Introduction: Why does one need IComparable? (And, I could not get an answer that I can use for teaching).
  • Structure of IComparable (Again, what else can I talk about other than CompareTo method).
  • Sample Code
  • Where we can use that in our project
  • Questions.
  • It's more of a contract than an implementation. By calling it IComparable, for instance, it's like you're saying that this object can be ordered or compared with another of its own kind. While it's true you can take advantage through sorting and whatnot, the bigger advantage is what you haven't yet written with it that may pop up in the future.
    – Neil
    May 3, 2012 at 15:33
  • 2
    Showing an alternative to existing code should get their attention and put the use into context.
    – JeffO
    May 3, 2012 at 16:41

5 Answers 5


Introduction: Why does one need IComparable? (And, I could not get an answer that I can use for teaching).

Because you want to be able to compare different type of objects without worrying how the actual comparison is done. You want to declare a responsibility and not worry about actual implementation as it may vary. Interface does just that.

It's concerned with comparing objects. Nothing more, nothing less.

Structure of IComparable (Again, what else can I talk about other than CompareTo method).

There is no implementation or structure as such. It exposes a behaviour, or a concern. There is nothing more to it.

Sample Code

  • Declare an interface
  • Create two implementations
  • Make an emphasis that you don't care about how implementations work, all you care about is being able to compare objects.

Where we can use that in our project

  • Comparing investments is interesting. Investment X might be less profitable, as profitable or more profitable than investment Y.

You can then define the following interface:

public interface IComparable<IInvestment> 
   int Compare(); 

You can have two implementations of IInvestment: RealInvestment and FakeInvestment (dummy version for unit tests and mocks)

Finally, you'll have two different comparison routines for real and fake investments:

public RealInvestmentComparable : IComparable<RealInvestment>
    // Implement interface

public FakeInvestmentComparable : IComparable<FakeInvestment>
    // Implement interface 

If you can base your training on a different interface, then maybe it's a better idea. It's normally very easy to talk about IRepository. You can then have multiple implementations of that repository, e.g. FakeRepository, EFRepository. You can use fake repository with unit tests.


You really need to express the benefits of using these interfaces. I personally have found them useful when storing domain objects in collections and needing to either sort the collections or search for items in the collections.

Demonstrate the necessary code to do sorting/searching in a collection without using these interfaces and then demonstrate how using these interfaces makes the necessary code easier to maintain and use. Use the example you mentioned with the Discount class if you want, or any other class that your team is already familiar with.


The main utility of the built-in interfaces is that they are built-in; if you need to define that two objects can be compared for equality, IEquatable is right there. Same for IComparable and the ability to compare for relative magnitude.

This leads to another main reason why you'd use them; the .NET Framework does. Linq looks to see if the objects are ICompatable/IEquatable and uses those implementations when it can. Collections that are sortable require IComparable; collections with IndexOf()-type methods generally require IEquatable implementations on their collected type. So, in order to use what the Framework gives you, you have to use what the Framework gives you.

So, to answer the questions you pose in your template succinctly:

  • Conceptually, you need IComparable whenever you need to tell other code that this object can be compared to another object to determine relative magnitude. That other code then knows, much like any other interface, the exact name and signature of the method to call to perform this operation.

  • IComparable's "structure" IS the declaration of the CompareTo() method that takes an Object (in the non-generic variant) or an object of a strongly-defined type (for the generic interface; usually this type is the same type as the class). The only other thing you have to discuss is the expected result; a value of zero if the two instances are equal, a value of less than zero if the instance on which you are calling the method precedes the instance passed as the parameter, and a value greater than zero if the instance on which the method was called succeeds the instance passed as the parameter.

  • Code samples abound; check the MSDN documentation.

  • Pretty much anything you need to be able to sort by some default, esoteric subset of its data.


Since you are looking for examples for IComparable, why not try something simple (everyone likes money): revenue and expenses ? Or compare different people's skills from a human resource perspective (creating simple but different metrics for developers, engineers, accountants, machine operators...) You can build a very simple example based on this idea, touching every item on your list. So the answer "why use IComparable" would be something like being able to compare characteristics of dissimilar objects based on a single similar characteristic... I like the idea of trying to get the same program to work with, or without IComparable or other nice interfaces.


Personally I always prefer to implement an IComparer rather than ICompare. ICompare is great in simple cases, but sometimes IComparer will give you more flexibility. One instance that springs to mind is a flight comparer I had to write, in some scenarios just being the same route was enough, in others you had to fly the same route on the same day and in a third example it needed to be the same flight.

You could use this flight example as an example, I think it's a real world solution that most people would understand.

Not the answer you're looking for? Browse other questions tagged or ask your own question.