Is there a cleaner approach to matching class types in this observer like pattern?

Question

I have written an implementation of the observer pattern that allows messages to be passed to listeners in what would normally be the notify() method. For example a subscriber sub-class might look like the pseudo-code below, where Message is a simple class that can be sub-classed and made to contain value objects or other data.

class MySubscriber extends Subscriber
{
    @Override
    public void notify( Message m )
    {
        if( m.getClass == MyMessage )
        {
            MyMessage myMessage = ( MyMessage ) m;
            if( myMessage.name == MyMessage.START )
            {
                // -- Finally do something here
            }
        }

        if( m.getClass == MyOtherMessage )
        {
            MyOtherMessage myOtherMessage = ( MyOtherMessage ) m;
            if( myOtherMessage.name == MyOtherMessage.INIT_SOMETHING )
            {
                // -- Finally do something else here
            }
        }

    }  
} 

Using conditionals like this to determine the message type seems a bit redundant and can get tedious in cases where a subscriber is listening for many message types. However, it is pretty explicit, easy to read and the implementation is quite simple. Is there a cleaner approach to achieve a similar result?

Btw, I attempted to add the tags: "observer" and "introspection" to this question but apparently I don't have enough points on this Stack Exchange site.

Answer 1

Personally I prefer polymorphism instead of conditions in such cases, as it helps to keep big conditions in a clean fashion - each condition in it's own class. As an example, in .NET they have generic event-handlers (subscribers) and following class system takes place (or something along these lines):

abstract class EventArgs { ... } // your abstract data class, Message if you will
class MyEventArgs : EventArgs { } // and it's implementation

abstract class EventHandler<T> // an abstract Subscriber
{ 
    public abstract Notify(T args); // Subscriber::notify() in your example
} 

class MyEventHandler : EventHandler<MyEventArgs>  // an implementation of a subscriber for one specific case, which would be MyEventArgs
{
    public Notify(MyEventArgs args) { ... }
}

Answer 2

Just a couple of thoughts as it's hard to tell without more background:

• Do you really want to use the == operator here, perhaps you should be using instanceof.

• If the Subscriber needs to handle various types of messages why not include those types explicitly in theinterface? I think it makes it clear what the code sending the message intends, rather than funneling all messages through a single method. This may allow for compile time type checking.

• Consider making a separate subscriber interface for each type of subscriber.