Obviously, the possible combinations of overloaded methods explodes as the number of options increases. It is not hard to understand why API programmers can seem to get carried away and offer too many overload choices. Overloading methods provide a clean and simple way to add flexibility to an API, but at some point the simplicity diminishes and the value of overloading rapidly decreases. Where is this point? It probably depends on the particular reader, but also on basic cognitive capabilities of humans in general (the number seven comes to mind as being the place where most eyes begin to glaze over).

I recently needed to use the DrawImage() method of the Graphics object in Microsoft .NET. I was horrified to find that it had no less than 30 overloads! *

I had been coding happily along when I came up against this veritable Medusa of methods. I foolishly stared straight into the face of this beast and became completely derailed. I was dismayed that I had to stop my train of thought and sift through this massive list of overloaded methods to find the one that was right for me.

(It was almost as annoying as not being able to come up with decent metaphors to mix while writing about it.)

Even with this ridiculous number of overloads, I had no option but to choose one that didn't quite match my needs. The one I needed had the parameters I required and several that I didn't (I wanted to resize the destination image, but I didn't care about using the abort callback, or selecting a sub-region in the original image). In other words, there weren't enough overloads! No, I'm not asking for more (please, please, no!), I'm asking for something different.

How Overloading Can Be Reduced?

How do you solve this problem? It connot be intractable. Can it? In any event, the first step toward solving it is at least caring about it.

Some languages don't have this problem. For example, in Python you can't have a bunch of different overloads of the same method. Instead you can use named arguments (it really boils down to using a dictionary). You would have a single drawImage() method whose usages look something like this:

graphics.drawImage( image, x = 100, y = 100, border = True )

graphics.drawImage( image, width = 400, height = 200 )

In Java, you could simulate this with a Map, but there would probably be great hue and cry if you suggested this, since it would contain a heterogeneous collection of objects. Its usage and implementation would probably be too clunky anyhow. For example, usage might look like this:

Map params = new HashMap();
params.put( "x", new Integer(100) );
params.put( "y", new Integer(100) );
params.put( "width", new Integer(100) );
params.put( "height", new Integer(100) );
params.put( "border", new Boolean(true) );

graphics.drawImage( image, params ); 

C# could handle the variable parameter list much better than Java, using the params keyword. The method would be implemented like this:

   public class Graphics
   {
      // ...
      public void drawImage( Image image, params object [] options )
      {
         // Unpack all the possible parameters.
      }
      // ...
   }

   graphics.drawImage( image, "x", 100, "y", 100, "width", 400, "height", 300, "border", true );

   graphics.drawImage( image, "x,y,width,height,border", 100, 100, 400, 400, true );

Another solution is to create some helper objects to aggregate parameters. This is common in C, where you create a structure, zero it out and populate the relevant elements. Of course, C doesn't have the option of overloaded functions, so other than having zillion parameters, that is really the only option there. I haven't seen this done much in object-oriented languages.

C and C# also have the ability to handle variable-length argument lists. In C, it is not very useful unless the first parameter in the list tells you what type the other parameters are (or unless you come up with some scheme to make them self-descriptive). In C#, you get an object array, so you could use reflection on each of the elements, but that would hardly be elegant and wouldn't let you distinguish between objects of the same type (is an int the x coordinate? y? width? height?).

Another idea would be to have the target object collect information, like this:

graphics.setX(100);
graphics.setY(100);
graphics.setWidth(100);
graphics.setHeight(100);
graphics.setBorder(true);

graphics.drawImage(image);

Is there an elegant solution for this problem in Java and C#, or is this just something we have to live with in statically-typed languages?

Style style = new Style();
style.setBorder(true);
 
graphics.drawImage(image, 
                   new Rectangle(100, 100, 100, 100), 
                   style);

> Style style = new Style();
> style.setBorder(true);
> 
> graphics.drawImage(image,
> new Rectangle(100, 100, 100, 100),
> style);
> 

> Style style = new Style();
> style.setBorder(true);
> 
> graphics.drawImage(image,
> new Rectangle(100, 100, 100, 100),
> style);
> 

graphics.drawImage( image, new ImageOptions() {x = 100; y = 100; border = true;} );
 
graphics.drawImage( image, new ImageOptions() {width = 400; height = 200;} );
 
graphics.drawImage( image, null );