Object Oriented approach to receiving messages

[Brian]

Hi,

I come from a C background. I am trying to receive messages over a serial
port. The message data structure format is along the lines of

int message_id;
int message_length;
int data[message_length];

There will be different messages received with different IDs and variable
lengths.

If I were to write this in C I would use something like:-
switch (message_id){
case 1:
decode_message();
add_to_msg_processing_queue();
break;
....
}

There will also be a transmit routine to write too.

Now I don't feel that this is very good object oriented approach. Could
anyone suggest a better way to handle this type of message structure in C#?

Thanks

[S. Senthil Kumar]

You can try using the Factory pattern. Basically, you have a class for
each type of message and that class will be responsible for decoding
and further processing of the message.

The factory then creates appropriate objects, based on the message ids
and then passes the message structure to that object for further
action.

Regards
Senthil

[S. Senthil Kumar]

You can try using the Factory pattern. Basically, you have a class for
each type of message and that class will be responsible for decoding
and further processing of the message.

The factory then creates appropriate objects, based on the message ids
and then passes the message structure to that object for further
action.

Regards
Senthil

[Helge Jensen]

Brian wrote:

There will be different messages received with different IDs and variable
lengths.

You need to dispatch to code depending on ID, right? If you need to
dispatch on predicates on ID you need to get a bit more clever than this.

Setup an IDictionary from ID's to functions:

class Handlers: Hashtable {
public static Handlers Global = new Handlers();
public delegate void Handler(int id, Stream s);
public Handler Register(int id, Handler handler) {
Handler old = this[id];
this[id] = handler;
return old;
}
public void Dispatch(id id, Stream s) {
((Handler)this[id])(id,s);
}
}

Register all the handlers for different ID's:

Handlers.Global.Register(new Handler((new HandlerForSomeId()).f));
...

Read input, something like:

while ( true ) {
int id = ReadIdFromStream(s);
Handlers.Global.Dispatch(id, s);
}

Now, the handler, can read from the stream and place and objects
constructed from the stream in any queue's relevant to processing.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Helge Jensen]

Brian wrote:

There will be different messages received with different IDs and variable
lengths.

You need to dispatch to code depending on ID, right? If you need to
dispatch on predicates on ID you need to get a bit more clever than this.

Setup an IDictionary from ID's to functions:

class Handlers: Hashtable {
public static Handlers Global = new Handlers();
public delegate void Handler(int id, Stream s);
public Handler Register(int id, Handler handler) {
Handler old = this[id];
this[id] = handler;
return old;
}
public void Dispatch(id id, Stream s) {
((Handler)this[id])(id,s);
}
}

Register all the handlers for different ID's:

Handlers.Global.Register(new Handler((new HandlerForSomeId()).f));
...

Read input, something like:

while ( true ) {
int id = ReadIdFromStream(s);
Handlers.Global.Dispatch(id, s);
}

Now, the handler, can read from the stream and place and objects
constructed from the stream in any queue's relevant to processing.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Javaman59]

Hi,

I've had to do this sort of thing with OOP in the past. In general, I've
used a class for each message type, and had a heirarchy of classes where
there is a genuine heirarchy in the messaage types...

eg

class NavigationalMsg

abstract class TrackMsg

class AirTrackMsg: TrackMsg

class SurfaceTrackMsg: TrackMsg

class StationaryTrackMsg: TrackMsg

Where to decode the raw messages is an interesting problem. Here are some
ideas...

1. The constructor for each class takes raw data (either binary, or ASCII),
and parses it,
2. The constructor for each class takes the decoded values (eg. position,
color, ...), and a separate parser parses the incoming stream, and constructs
the appropriate message classes,
3. The Factory design pattern, as suggested by Senthil. I have heard of this
being used for this problem, but haven't tried it myself.

You might be surprised how much of an overhead is involved in creating a
class for each message type - it is considerably more work than just using
the inline decoding of each message which you described. C# helps by having
Properties. This extra work is only useful if you find that you are using
these message objects throughout your program. If you are just using them
once, to decode the input stream, then it is probably not worthwhile. On the
other hand, if this is your first Object Oriented design, I would recommend
using the message classes, just for the experience, and to see how it
compares with what you are used to.

Regards,

Javaman

"Brian" wrote:

Hi,

I come from a C background. I am trying to receive messages over a serial
port. The message data structure format is along the lines of

int message_id;
int message_length;
int data[message_length];

There will be different messages received with different IDs and variable
lengths.

If I were to write this in C I would use something like:-
switch (message_id){
case 1:
decode_message();
add_to_msg_processing_queue();
break;
...
}

There will also be a transmit routine to write too.

Now I don't feel that this is very good object oriented approach. Could
anyone suggest a better way to handle this type of message structure in C#?

Thanks

[Javaman59]

Hi,

I've had to do this sort of thing with OOP in the past. In general, I've
used a class for each message type, and had a heirarchy of classes where
there is a genuine heirarchy in the messaage types...

eg

class NavigationalMsg

abstract class TrackMsg

class AirTrackMsg: TrackMsg

class SurfaceTrackMsg: TrackMsg

class StationaryTrackMsg: TrackMsg

Where to decode the raw messages is an interesting problem. Here are some
ideas...

1. The constructor for each class takes raw data (either binary, or ASCII),
and parses it,
2. The constructor for each class takes the decoded values (eg. position,
color, ...), and a separate parser parses the incoming stream, and constructs
the appropriate message classes,
3. The Factory design pattern, as suggested by Senthil. I have heard of this
being used for this problem, but haven't tried it myself.

You might be surprised how much of an overhead is involved in creating a
class for each message type - it is considerably more work than just using
the inline decoding of each message which you described. C# helps by having
Properties. This extra work is only useful if you find that you are using
these message objects throughout your program. If you are just using them
once, to decode the input stream, then it is probably not worthwhile. On the
other hand, if this is your first Object Oriented design, I would recommend
using the message classes, just for the experience, and to see how it
compares with what you are used to.

Regards,

Javaman

"Brian" wrote:

Hi,

I come from a C background. I am trying to receive messages over a serial
port. The message data structure format is along the lines of

int message_id;
int message_length;
int data[message_length];

There will be different messages received with different IDs and variable
lengths.

If I were to write this in C I would use something like:-
switch (message_id){
case 1:
decode_message();
add_to_msg_processing_queue();
break;
...
}

There will also be a transmit routine to write too.

Now I don't feel that this is very good object oriented approach. Could
anyone suggest a better way to handle this type of message structure in C#?

Thanks

[B]

There would be two main usages of data coming in.

1. One would be sent to a buffer for processing at a later stage i.e.
displaying of plot data.

2. The other would be dealt with immediately and would cause the GUI to be
updated with values, i.e. text files updated, status bar update, icons
changed etc. This type of message would also update and internal store of the
current data values.

So them messages do have a lifetime but it is limited.

I am not sure if I would want to create an object for every type. I am not
sure of the benefit.

Javaman59 in you suggestion I would pass the raw data into the contructor
which would then parse this raw data. To parse the data do I still not come
to the same situation of a switch (message_type).

I suppose I want to minimise code change when a new message type has to be
added.

Also in your abstract class TrackMsg would that consist of the common fields
and methods? Something like

TrackMsg
{
private int Message_Type;
private int Message_Length;

public GetMessageType();
public GetMessage_Length();

}

Thanks,
B

"Brian" wrote:

Hi,

I come from a C background. I am trying to receive messages over a serial
port. The message data structure format is along the lines of

int message_id;
int message_length;
int data[message_length];

There will be different messages received with different IDs and variable
lengths.

If I were to write this in C I would use something like:-
switch (message_id){
case 1:
decode_message();
add_to_msg_processing_queue();
break;
...
}

There will also be a transmit routine to write too.

Now I don't feel that this is very good object oriented approach. Could
anyone suggest a better way to handle this type of message structure in C#?

Thanks

[Javaman59]

Hello B,

Without knowing your application, I am cautious about giving specific
advice, but I will call it as I see it from here...

The use of a class for each message type is an overhead, but it is worth it
if the messages have some sort of lifetime, are used in a few different
places, and, if each message type has unique data. (If the different message
types have only a small amount of unique data, then you can make one just
class for messages, which aggregates all the message data). It looks to me as
if your application satisfies all of those conditions. One of the advantages
of using a class for each message type is that after you create them
initially (a day or two's work), they are very stable, and don't need much
maintenance. Also, it is easy to add new message types.

Javaman59 in you suggestion I would pass the raw data into the contructor
which would then parse this raw data. To parse the data do I still not come
to the same situation of a switch (message_type).
That is correct. Your top level message handler must parse enough of the
message to determine the message type, and make a switch to determine which
constructor to call, and then pass the rest of the raw message to the
constructor. (I believe that that the Factory pattern presents an alternative
to this, but I haven't used it yet).

I suppose I want to minimise code change when a new message type has to be
added.
You will achieve that with this object oriented design.

Also in your abstract class TrackMsg would that consist of the common fields
and methods? Something like

TrackMsg
{
private int Message_Type;
private int Message_Length;

public GetMessageType();
public GetMessage_Length();

}

Very good - you are on the way to mastering OO!! Just a couple of comments
on your code. 1. I recommend that you use C# capitalization conventions (see
my example below). 2. Your "Get" methods (which are called "accessors") are
correct, but C# gives a better approach, called "properties", which is just a
simpler syntax for accessors. C# makes it just a bit easier to create a class
for each message. 3. Use an "enum" for the message kinds, rather than an int,
because in C# enums help with strong typing (whereas they don't add much in
C++).

Here's how I'd code this class, with correct capitalization, and with
properties...

using System;

// Use an enum for the message kinds
// Pascal case (ie. leading upper), for the enum, and no underscores.
enum MessageKind
{
SurfaceTrack,
AirTrack
}

// Pascal case (ie. leading upper), for the class
class TrackMsg
{
// camel case (ie. leading lower case), for class members
MessageKind messageKind;
int length;

// The "get" accessor, as a property.
public MessageKind MessageKind
{
get { return messageKind; }
}

public int Length
{
get { return length; }
}
}

Good luck with it!

Javaman