Avoiding instanceof with a message server

Question

I have a system which is receiving 'messages' (simple objects containing nothing but fields and getters) and sending them to various GUI classes which will then display their data. There are many separate displays. Each display will receive a subset of the message types and will pull a subset of the data from each message it receives based on that display's needs. All of the messages subclass from one common superclass. So in the displays I want to be able to do something like:
update(SuperMessageType message);I could implement it with instanceof:
update(SuperMessageType message) {
    // do stuff
    if (message instanceof MessageOneType)
        int foo = message.getFoo();
    if(message instanceof MessageTwoType)
        int bar = message.getBar();
}but that's pretty ugly. Or I could make a bunch of overloaded versions of update, one for each message type both from the subject and in each observer:
update(MessageOneType message);
update(MessageTwoType message);
...Overloading seems to require modifying a lot more code (including adding all of the registerMessageOne etc. observers), without a lot of gain since the messages are simply fields and getters.
Any thoughts on which way would be better, or perhaps another alternative? Thanks!

Answer 1

GarrettAlexander wrote:
I have a system which is receiving 'messages' (simple objects containing nothing but fields and getters) and sending them to various GUI classes which will then display their data. There are many separate displays. Each display will receive a subset of the message types and will pull a subset of the data from each message it receives based on that display's needs. Why? What makes the "Messages" part of that inheritance besides the fact that you made them that way?
Any thoughts on which way would be better, or perhaps another alternative?Presuming that there is in fact a reason for this and for the GUIs that do not mandate that the must be manually created regardless then one could use code generation or a hash/dictionary storage mechanism. Of course you do the second because the requirements/design drive to that rather than because one wants to save typing.