Imagine you want some of your clothes to be dry cleaned. Typically, you stop by the dry cleaners and hand them a bunch of clothes, with an order "clean it!" (I am usually more polite, but we'll be rude for the sake of this discussion). The guy behind the counter at the dry cleaners' knows that they clean shirts, suits, and other stuff. If he sees a PDA among the clothes, he would probably say, "We do not clean it."

Now let's turn to the wonderful world of software. When you write a class, you may want to perform the same action, but take in different parameters for that action. By handing in the clothes, I called the method clean() on the DryCleaners class. What I passed in is an argument, and it's different every time I stop by to clean something. Today, I want my shirts cleaned, so I call method clean(Shirt shirt); tomorrow, my wife includes a dress in the laundry basket, so I call clean(Dress dress). The dry cleaners outfit understands what to do with the clothes (if they need to be treated differently) based on the type of parameter passed in. I do not have to remember what specific things need to be done for each type of item, and I do not have to go to a separate window for shirts and dresses. This is called method overloading. In this article, I'll explain how method overloading is implemented in .NET, and what we can do about overloading in the Web Services world. (I don't think I can help you with your laundry problems.)

Method Overloading in C#

Strictly speaking, method overloading is the ability to define several methods, all with the same name. Let's start with a simple example; it would be nice to have a class with the ability to return a nicely formatted string for our custom type BankCard. We implement a PrettyPrinter class:

using System;

class PrettyPrinter
{
  public string print(BankCard card)
  {
   return card.owner + "\'s " + card.brand + " Num "
     + card.number + "; exp " + card.expDate; 
  }  
}

Calling PrettyPrinter.print(myCard) returns something like this:

Max's MasterCard Num 1234567812345678; exp 12/99

Pretty useful, isn't it? Later, down the road, we decide to add the same functionality for our CheckingAccount type. The nice thing about overloading is that you can still use exactly the same method name; just provide different argument types. The compiler figures out for you which particular method should be called. Now our implementation of PrettyPrinter would look like this:

using System;

class PrettyPrinter
{
  public string print(BankCard card)
  {
   return card.owner + "\'s " + card.brand + " Num "
    + card.number + "; exp " + card.expDate; 
  }

  public string print(CheckingAccount account)
  {
    return account.owner + "\'s checking account No "
     + account.number;
  } 
}

In our little test snippet we'll call both methods:

BankCard card = new BankCard();
CheckingAccount account = new CheckingAccount();

...

Console.WriteLine(PrettyPrinter.print(card));
Console.WriteLine(PrettyPrinter.print(account));

After we run this fragment, we should see approximately the following printed to the console, provided we initialized the objects first:

Max's MasterCard Num 1234567812345678; exp 12/99
Max's checking account No 62626262

As you just saw, overloading might prove pretty useful. Here is a word of caution: try to use overloading only when all implementations of the overloaded method do more-or-less the same thing. In this case, all implementations format the object to be presented as a human-readable string. By sticking to this rule, we make life easier for other developers who would use our overloaded methods.