Skip to Content.
Sympa Menu

patterns-discussion - [patterns-discussion] Pattern Selection Question

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

[patterns-discussion] Pattern Selection Question


Chronological Thread 
  • From: Andre <andre.2995 AT gmail.com>
  • To: patterns-discussion AT cs.uiuc.edu
  • Subject: [patterns-discussion] Pattern Selection Question
  • Date: Mon, 3 Oct 2005 10:59:13 -0500
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nX29FoTpbwLfmAbpQb4gjaGEGxu9bKfxHMPaN7ZR6dqhYRAvhvNCPumOvWOsnNH4kEBCDL4EjMknB+1CRZ0Eea2UiKU1XVoiO0Eql05tiSgdRDsW+MU7D86QpQu7bSUfj/+ySE99piLa96zxIfgOUUeTFTGgqXWZmzKbF57JbcY=
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/patterns-discussion>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>

Hi there,

I have a question about what type of Pattern might best fit an
application. Here is a synopsis:

We have embedded software that can access several types of "receivers"
that all transmit data over a serial port. Many of the receivers use
the same protocol, but some use a different protocol. By protocol I
mean that they have different control bytes signaling the beginning
and end of the message, and different header contents that usually
specify A) the message type and B) the message data length.

So basically a message always looks like this, regardless of the protocol:

Message "Start" qualifier
Message Header, including message type and length
Message Data, which includes data formatted for a message type.

So basically, the message is unpacked and then sent to a handler
routine based on the message type, if the message is valid (each
message is typically checksummed or CRCd to determine this within the
protocol).

Another part of the story is that, the receivers that use the same
protocol also handle none, some or most of the same message types, but
the message types that they handle depend on the application.

The code is a mess right now and I can't post any of it for reasons I
cannot supply. Basically it comes down what I see as a state pattern
for the protocol:

Look for message start.
Message start received, look for message header.
Message header valid, look for data.
Data valid, process the message based on the message header.
- Any step that fails, look for a new message start.

I was also considering strategy, because how the code goes about
looking for a message start, etc. differs per protocol.

In terms of handling the messages, if I created some kind of receiver
class full of routines to handle each message sent by the receiver,
there would be some code duplication because different receivers
sometimes handle the same messages in the same exact way.

I hope this email is complete enough and/or the problem common enough
for someone to suggest a solution. Right now we are using #ifdefs in
very structured code to handle each receiver in its unique fashion,
and its not pretty.

Thanks,

Andre





Archive powered by MHonArc 2.6.16.

Top of Page