Ranjan Sakalley

Multiple overloads with distinguishing parameter as object is dangerous

From John Papa's post to Jackie Goldstien's that quoted Pablo Castro[MS], got these words that were somewhere in my mind but never expressed. Thanks all.

In general, having multiple overloads where the distinguishing parameter type is “object” in one of them is a dangerous thing to do.

Published Apr 06 2005, 11:37 PM by rsakalley

Filed under: Code

Comments

John Papa said:

Got to love blog chains! ;-)

Yeah, I found that interesting as well.

# April 7, 2005 4:50 AM

Raymond Lewallen said:

It can be dangerous, but usually isn't an issue. The compiler is pretty good at matching up strongly-typed parameters with whatever data types you are passing in, therefore almost always choosing the right overloaded method, which is not going to the overloaded method that takes an object type. I actually tested this type of thing out a while back. My conclusion was that as long as you provide the overloaded method with the matching datatypes, the overloaded method with object datatypes won't be used, and it won't be an issue. Just as soon as I post this somebody will certainly come back with some code to prove me wrong :) but try it out for yourselves.

Public Sub Bar(ByVal name As String, ByVal age As Int32)

Public Sub Bar(ByVal name As Object, ByVal age As Int32)

Public Sub Bar(ByVal name As String, ByVal age As Object)

Public Sub Bar(ByVal name As Object, ByVal age As Object)

Public Sub TestTheBar()
Me.Bar("Raymond Lewallen",29)
End Sub

Its going to choose Bar(string,int32) in this case, and in pretty much all cases I tested when providing the correct overloaded methods.

I think the SqlParameter.Add() was an exception in the fact that the compiler would chose the wrong overload.

# April 7, 2005 5:39 AM

Brendan Tompkins said:

I read somewhere, and I really have to go back and find the source, that multiple overloads in and of themselves are usually a sign of a poorly designed object model.

I've found this to be true in a lot of situations. It's just one of those things I keep in mind when I find myself with more than 2 or 3 overloads.

# April 7, 2005 7:02 AM

Joshua Flanagan said:

The difference between your example, and SqlParameterCollection.Add(), is that your overloads that take 2 parameters have the same meaning. In all of your overloads, the 2nd parameter sets the age. In the SqlParameterCollection, the overload that takes a SqlDbType has a different meaning than the overload that takes an object.
That is where it is dangerous, since you don't know which implementation it will choose.
When you say:
SqlParameterCollection.Add("param" 0)
- the compiler could interpret that as "create a parameter with this data type, without setting the value", or "create a parameter with this value".
Sure, if both overloads were performing the same functionality (as in your example), it would not be a problem.

# April 7, 2005 7:09 AM

Raymond Lewallen said:

Josh, I agree. I was just pointing out that I believe SqlParameter.Add is the exception to the case, and that under most normally designed overloaded methods, worrying about the object parameter overload wouldn't be an issue.

# April 7, 2005 7:40 AM

John Papa said:

I agree that overloaded methods should be used in moderation just like optional parameters should be used in moderation. I just ran through some code last week where I saw 12 overloaded methods to save data! (It is now down to 3.) Overall I love overloading and actually prefer it to optional parms, but I have no reasoning for that other than personal preference.

# April 7, 2005 7:56 AM