Finding method by signature at runtime

  • Thread starter Thread starter Pekka Henttonen
  • Start date Start date
P

Pekka Henttonen

Let's say there is an object which has several methods all taking
different object as argument:

class TestObject {

public void SetTitle( TitleObject title );
public void SetDate( DateObject date );
<etc.>
}

How can you find out which method to call at runtime when you have an
object which should be passed to a method? I suppose there is a cleaner
way to do it than by testing all possibilities by a set of if-clauses:

public void SetNull( Object o ) {

if ( o is TitleObject ) {
SetTitle(null);
} else
if ( o is DateObject ) {
SetDate(null);
} else
<etc.>

}

With best regards
Pekka
Kerava, Finland
 
You don't actually need to do that. The compiler can do that for you if you
just overload a single "Set" method:

public void Set(TitleObject title) {
_title = title;
}
public void Set(DateObject date) {
_date = date;
}
// etc...

Because the method signatures differ, the compiler can figure out which one
you want at compile time based on the type you're passing in. Sadly, the
same trick doesn't work quite as cleanly for a "Get" function, because
return type is not part of a method's formal signature. The best you can do
on the flip side is to implement a generic "get" like this:

public object Get(string fieldname) {
switch(fieldname) {
case "title": return (object)_title;
case "date": return (object)_date;
default: return (object)null;
}
}

This works fine, but requires the caller to cast the result to the desired
type, which you can't necessarily trust them to do correctly.
 
P.S. If the code that's calling your overloaded Set() method actually has a
TitleObject or a DateObject at hand, then my approach works fine. Upon
re-reading your question, though, that isn't clearly stated. If the caller
merely has a generic object, and it doesn't know what derived type the
object is either, then I'm hard-pressed to think of a solution that doesn't
involve reflection. But if the caller doesn't know what kind of thing it's
trying to set either, then your program may have bigger problems than
this...

--
Anything I post is solely my opinion, and is not necessarily representative
of my employer's positons.
My answers are not always correct, but I do my best to be accurate and
helpful.
 
You don't actually need to do that. The compiler can do that for you
if you just overload a single "Set" method:
Click to expand...

Thanks, I know that. It would be the easiest way to approach the
question. But I am not sure how it fits into the bigger picture. I must
give it a thought.

I suppose also null objects have a type? Would the compiler know what
method should be called if the object (in the example DateObject or
TitleObject) passed is null?
P.S. If the code that's calling your overloaded Set() method actually
has a TitleObject or a DateObject at hand, then my approach works fine.
Upon re-reading your question, though, that isn't clearly stated. If
the caller merely has a generic object, and it doesn't know what
derived type the object is either, then I'm hard-pressed to think of a
solution that doesn't involve reflection.
Click to expand...

The program knows that it is dealing with an object derived from a base
class but not exactly what type of object it is. There is no serious
problem :-)

I thought that the reflection might also do the trick, but I do not know
enough about it to use it.

With best regards
Pekka
 
Pekka Henttonen said:
Thanks, I know that. It would be the easiest way to approach the
question. But I am not sure how it fits into the bigger picture. I must
give it a thought.

I suppose also null objects have a type? Would the compiler know what
method should be called if the object (in the example DateObject or
TitleObject) passed is null?
Click to expand...

There's no such thing as a null object. However, the compiler resolves
overloads at compile time, not at runtime. It looks at the type of the
expression and decides which method to call based on that.
 
Back
Top