different message classes

On a quick read, this sounds like a base class for the common knowledge and behavior and subclasses for the specific message types with the type specific knowledge and behavior.  Then, you can pass things as either the specific subtype or the superclass as needed.

MessageType is an enum of


QueueStatus

CampaignStatus

AgentStatus

NewCall

EndCall

...

WhateverTypeIwant







Each message type can have a number of fields (QueueGUID, CampaignGUID, AgentGUID etc etc). Some of these fields are common across message types, others not.




So, to my question:




When I receive this message, should I create a single message class, which has all possible fields defined, or a particular message class for each type of message ?




This object is then "published" to all subscribers of the message type.




If I chose the second option, should I




a) create an interface "foo", with the common methods and properties, and then a new class for each type that implements that interface,


b) create a base class with the common methods and properties, and then a new class for each type that inherits the base class




with (a) I can define the parameter as class "foo" , but can I access the distinct properties (I could CAST, I suppose ...)


with (b) I have to specify each parameter as the particular class, and each PUBLISH would have to be seperate to cater for each message class parameter

I'd vote one OO type/class per MessageType. They can inherit common state or behaviour. Each MessageType encapsulates only that MT's behaviour. So (b) above.

My general preference is to go with interfaces over types as arguments. But in this case where the type largely has state I'd pass the object (NewCall, say) rather than an interface. The openness of the API also plays a role in this decision for me.

-- peter