Dynamic Method Dispatching Problem
Hi, my situation is as follows:
I have and abstract parent class, and numerous child classes. Within the child classes are various methods which as input should allow an object of one of the child classes. The code for the method is as follows:
public <name>(ParentObject input1){
input1.simulate();
....
Method simulate is defined as abstract in the parent class, and each of the child classes have their own simulate method defined. Shouldn't the above automatically attempt to run the simulate method of the actual class of the parameter?
[585 byte] By [
SebCachiaa] at [2007-11-27 0:56:53]
Basically yes. Do you have a problem?
Yes it will call the simulate method in the derived class. Isn't that working for you?
apppua at 2007-7-11 23:30:10 >
> ...> Shouldn't the above> automatically attempt to run the simulate method of> the actual class of the parameter?When the method <name> is called, the simulate() method of input1 is invoked. Do you think
> > ...
> > Shouldn't the above
> > automatically attempt to run the simulate method
> of
> > the actual class of the parameter?
>
> When the method <name> is called, the
> simulate() method of input1 is
> invoked. Do you think otherwise?
providing such a method exists on that class, naturally
> ...> providing such a method exists on that class,> naturallyThe simulate() method is defined as an abstract method in it's parent class.
Hi, an update on the problem, it seems that the problem lies in the parent class.
The simulate method is defined as follows:
public abstract <ParentType> simulate()
throws UninitialisedException;
If i remove the UninitialisedException it runs correctly. Only when it is there it reports that :
unreported exception UninitialisedException; must be caught or declared to be thrown
I cant change the parent class and am not sure on how to go about working with this exception in the method in question. Any ideas?
> > > ...
> > > Shouldn't the above
> > > automatically attempt to run the simulate method
> > of
> > > the actual class of the parameter?
> >
> > When the method <name> is called, the
> > simulate() method of input1
> is
> > invoked. Do you think otherwise?
>
> providing such a method exists on that class,
> naturally
That class wouldn't compile if it didn't implement the simulate method (providing it extends the abstract class in which the abstract simulate is defined, naturally)
> > > > ...
> > > > Shouldn't the above
> > > > automatically attempt to run the simulate
> method
> > > of
> > > > the actual class of the parameter?
> > >
> > > When the method <name> is called, the
> > > simulate() method of input1
> > is
> > > invoked. Do you think otherwise?
> >
> > providing such a method exists on that class,
> > naturally
>
> That class wouldn't compile if it didn't
> implement the simulate method (providing it
> extends the abstract class in which the abstract
> simulate is defined, naturally)
nobody's said it compiles, yet, though. what I mean is, the actual problem isn't really defined so far
> > > > > ...
> > > > > Shouldn't the above
> > > > > automatically attempt to run the simulate
> > method
> > > > of
> > > > > the actual class of the parameter?
> > > >
> > > > When the method <name> is called, the
> > > > simulate() method of input1
> > > is
> > > > invoked. Do you think otherwise?
> > >
> > > providing such a method exists on that class,
> > > naturally
> >
> > That class wouldn't compile if it didn't
> > implement the simulate method (providing it
> > extends the abstract class in which the abstract
> > simulate is defined, naturally)
>
> nobody's said it compiles, yet, though. what I mean
> is, the actual problem isn't really defined so far
That's true. And the original question didn't seem to be linked to something concrete anyway. So we don't have to keep our fingers in those gearings.
hi, the method does exist in the child class, and ive just found out that it does work correctly if the previously mentioned exception is removed from the parent class. however removing the exception from the parent class is not an option. With the exception present the previously mention compile error takes place. How am i meant to deal with it?
Im afraid that it seems the problem wasnt dynamic method dispatching after all, but rather exceptions :S
As said by your compiler, you have to either catch it or declare it to be thrown by the <name> method, depending on whether this method can handle it or not.I guess the superclass documentation provides information on when/why this exception is supposed to be thrown.
