AFAIK, no, there isn't. It might help a bit if you actually give all
your "overloaded" methods the same name, e.g.

<code>
public void receiveMessage(Message m) {
 if (m instanceof StopMessage)
   receiveMessage((StopMessage) m);
 }
}
</code>

   but this will only work if, in the calling code, you already knew you
had a StopMessage as opposed to a generic Message.

   You might want to try something like a Visitor pattern, but this might
force your messages to become aware of the classes that handle them.

<code>
abstract class Message {
 public abstract void accept(MessageHandler mh);
}

class StopMessage extends Message {
 public void accept(MessageHandler mh) {
   receiveMessage(this);
 }
}

class GoMessage extends Message {
 public void accept(MessageHandler mh) {
   receiveMessage(this);
 }
}

MessageHandler {
 public void receiveMessage(StopMessage sm) {
   //Do something useful.
 }

 public void receiveMessage(GoMessage gm) {
   //Do something useful.
 }

 public void receiveMessage(Message m) {
   m.accept(this);
 }
}
<code>

   - Oliver

    Are you always calling a method with the same signature
regardless of the particular message subtype?  If so, why do you need
to know the subtype in receiveMessage()?

    In general, having to perform type identification at run time is
a "code smell" that indicates you should be using a different
approach.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.    | The experts in large scale distributed OO
                        | systems design and implementation.
         pjm@spe.com    | (C++, Java, Common Lisp, Jini, CORBA, UML)

What kind of control do you have on these classes? Can you change the
message class hierarchy? If you need to do different handling based on
the runtime type of object "m" (input to receiveMessage) , then it has
to be coded *somewhere*. If possible, you could probably change the
Message class/interface to support a getType()  .. which can be used
with a MessageProcessorLocator to locate a Processor.

Message
{
    public MessageType getType() ;
}
MessageProcessorLocator
{
    MessageProcessor locateProcessor(MessageType type) ;
}
MessageProcessor
{
    void  processMessage(Message msg) ;
}
StopMessageProcessor implements MessageProcessor
{

}
You can then maintain a map of MessageProcessors in the locator object
keyed using the message types.
Locator object can use this map to locate message processors.
If you implement your Map and Locator properly, you will not have to
worry about ugly "if" or switch constructs.
Abhijat

If you use a type field in the Message class you can forego the if
statements in favor of a switch statement.

public void receiveMessage(Message m)
{
  switch(m.getType())
  {
     case m.STOP_TYPE:
        parseMessage((StopMessage)m);
        break;
  }
}

If appropriate, you could also consider a change in design to use
polymorphism instead.  You would then implement the class that parses the
messages as a listener, and register it on the Message.

public void receiveMessage(Message m)
{
  m.setListener(this);
  m.parse();
}

class Message
{
  public abstract void parse();
}

class StopMessage
{
  public void parse()
  {
     listener.parseMessage(this);
  }
}

Neither of these solutions seems all that much cleaner or better than
your original though.

Another way to avoid type-tests is to use double-dispatch.  That can be quite
elegant where it is appropriate, but can also be used to "cover-up" bad design
(using the technical paraphinalia of OO programming to hide what is basically a
non-OO design).

   -- chris

In Java (and many other OO programming languages) there is the principle of
dynamic binding.

1    Parent instance = new Child();
2    instance.method1();

Assuming Child extends Parent & Child overrides method1(), in line 2
Child.method1() is invoced. This kind of dynamic binding is related to
overriden methods.

I've always wondered why there isn't something like dynamic binding based on
the (runtime) type of an argument, so dynamic binding related to overloaded
methods:

class Test{
   public void method1(Parent parent){...}
   public void method1(Child child){...}
}

1    Test test = new Test();
2    Parent instance = new Child();
3    test.method1(instance);

Why Java doesn't apply dynamic binding in this case? In line 3, the
invocation is statically (at compile time) bound to the Test.method1(Parent
parent), but I don't see which problems may arise when dynamic binding is
applied (so at runtime the decision is made to invoce Test.method1(Child
child) ).

All clarifying insights are greatly appreciated :-)

Jeroen