Richard Pope wrote:
[color=blue]
> I have some existing code that I am trying to upgrade to c++. The data in
> question is two bytes, which are used to identify what information is
> requested from an industrial computer (a PLC). The first few bits[/color]
represent[color=blue]
> the "category" of the data, and determine how the rest of the two bytes[/color]
are[color=blue]
> interpreted.[/color]
The existing code works. Leave it alone.
If you need the ability to easily change the code, write an emulator for
this hardware, then write lots of tests
If you need to improve other code's ability to call this code, wrap it in
"Facade" from the book /Design Patterns/.
There is no benefit to making a design "more OO" just for the sake of
changing it. And hardware generally dictates the design of code accessing
it. Just make sure that all other code in your system only calls the
interface of your Facade, and never gets its paws on any of those low-level
variables.
[color=blue]
> The existing code extracts various details from the data, but always uses[/color]
a[color=blue]
> switch statement on the category.
>
> I could write a single class in c++, but I would have a switch statement[/color]
in[color=blue]
> every member function. This doesn't feel right somehow.
> I could have a class for each category (inheriting from an ABC) but how do[/color]
I[color=blue]
> use them in practise? Do I need some kind of factory class that creates[/color]
the[color=blue]
> correct class, based on the category it extracts from the data?[/color]
Oh. Okay, in that case, you are correctly following this design rule: Never
use switch statements, except at an applications' boundary. Use either
Abstract Factory, Class Factory or Prototype Design Pattern to convert that
data, once, into an object. That will be the last switch statement. From
then on, only call virtual methods. Look up the refactor "Replace Type Code
with Subclasses" from the book /Refactoring/.
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces 
