Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Design of small related classes

Reply
Thread Tools

Design of small related classes

 
 
Richard Pope
Guest
Posts: n/a
 
      02-03-2004
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 represent
the "category" of the data, and determine how the rest of the two bytes are
interpreted.

The existing code extracts various details from the data, but always uses a
switch statement on the category.

I could write a single class in c++, but I would have a switch statement in
every member function. This doesn't feel right somehow.
I could have a class for each category (inheriting from an ABC) but how do I
use them in practise? Do I need some kind of factory class that creates the
correct class, based on the category it extracts from the data?


 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      02-03-2004
Richard Pope wrote:

> 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

represent
> the "category" of the data, and determine how the rest of the two bytes

are
> interpreted.


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.

> The existing code extracts various details from the data, but always uses

a
> switch statement on the category.
>
> I could write a single class in c++, but I would have a switch statement

in
> every member function. This doesn't feel right somehow.
> I could have a class for each category (inheriting from an ABC) but how do

I
> use them in practise? Do I need some kind of factory class that creates

the
> correct class, based on the category it extracts from the data?


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



 
Reply With Quote
 
 
 
 
Daniel T.
Guest
Posts: n/a
 
      02-04-2004
"Richard Pope" <(E-Mail Removed)> wrote:

> 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 represent
> the "category" of the data, and determine how the rest of the two bytes are
> interpreted.
>
> The existing code extracts various details from the data, but always uses a
> switch statement on the category.
>
> I could write a single class in c++, but I would have a switch statement in
> every member function. This doesn't feel right somehow.
> I could have a class for each category (inheriting from an ABC) but how do I
> use them in practise? Do I need some kind of factory class that creates the
> correct class, based on the category it extracts from the data?


Assuming that a particular bit of data never changes its "category" then
yes, I would probably use inheritance. You should have a factory method
that contains a switch statement that constructs a particular sub-type
based on the category. This function should return an auto_ptr<Base>
object.
 
Reply With Quote
 
Siemel Naran
Guest
Posts: n/a
 
      02-04-2004
"Phlip" <(E-Mail Removed)> wrote in message news:rBNTb.3211
> Richard Pope wrote:


> > 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
> > represent the "category" of the data, and determine how the rest of the

two bytes

> The existing code works. Leave it alone.


But it is properly factored? In each member function he has a switch
statement on the two bytes that represent the type.

--
+++++++++++
Siemel Naran


 
Reply With Quote
 
Siemel Naran
Guest
Posts: n/a
 
      02-04-2004
"Daniel T." <(E-Mail Removed)> wrote in message newsostmaster-
> "Richard Pope" <(E-Mail Removed)> wrote:


> > 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

represent
> > the "category" of the data, and determine how the rest of the two bytes

are
> > interpreted.


> Assuming that a particular bit of data never changes its "category" then
> yes, I would probably use inheritance. You should have a factory method
> that contains a switch statement that constructs a particular sub-type
> based on the category. This function should return an auto_ptr<Base>
> object.


Fine. Note that the factory method can use a table lookup (eg. a map<id,
object*>) instead of a switch. And a counterargument: the virtual pointer
is 4 bytes on a typical Intel/AMD box, whereas the original type is 2 bytes
(though who knows -- maybe there were 2 bytes padding).

--
+++++++++++
Siemel Naran


 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      02-04-2004
"Siemel Naran" <(E-Mail Removed)> wrote:

> "Phlip" <(E-Mail Removed)> wrote in message news:rBNTb.3211
> > Richard Pope wrote:

>
> > > 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
> > > represent the "category" of the data, and determine how the rest of the

> two bytes
>
> > The existing code works. Leave it alone.

>
> But it is properly factored? In each member function he has a switch
> statement on the two bytes that represent the type.


I think that depends... How many switch statements are there off of this
type, and are they all in the same class or spread out all over the
place?

I personally would probably factor the switch statements out just
because I don't like the code duplication, but depending on time
constraints and the likelihood that more types will be added in the
future, I may leave the switch statements in and call it "good enough".

Refactoring is great for making code easer to change, however if there
is no pressure for the code to change, there is little need to refactor.
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      02-04-2004
"Siemel Naran" <(E-Mail Removed)> wrote:

> "Daniel T." <(E-Mail Removed)> wrote in message newsostmaster-
> > "Richard Pope" <(E-Mail Removed)> wrote:

>
> > > 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

> represent
> > > the "category" of the data, and determine how the rest of the two bytes

> are
> > > interpreted.

>
> > Assuming that a particular bit of data never changes its "category" then
> > yes, I would probably use inheritance. You should have a factory method
> > that contains a switch statement that constructs a particular sub-type
> > based on the category. This function should return an auto_ptr<Base>
> > object.

>
> Fine. Note that the factory method can use a table lookup (eg. a map<id,
> object*>) instead of a switch.


I would only go that far if for some reason I needed to dynamicly change
what kind of object needs to be created for each type. Otherwise, one
switch statement does not constitute code duplication.


> And a counterargument: the virtual pointer
> is 4 bytes on a typical Intel/AMD box, whereas the original type is 2 bytes
> (though who knows -- maybe there were 2 bytes padding).


Good point, for this small of an object. The OP said the entire chunk of
data was only 2 bytes, the identifier was just a "few bits". Going with
inheritance would jack up the size of the object by quite a bit. More
than double...
 
Reply With Quote
 
lilburne
Guest
Posts: n/a
 
      02-04-2004


Daniel T. wrote:
>
> Refactoring is great for making code easer to change, however if there
> is no pressure for the code to change, there is little need to refactor.


Refactoring also offers the opportunity for adding new bugs. If the code
works it don't need fixing.

Only refactor code if it requires changing anyway. Then integrate the
refactored code into the product, running all the tests, before
embarking on the task that called for the refactoring in the first
place. Don't combine refactoring with bug fixing or code enhancement, if
it all goes tits-up you'll not know whether it was the refactoring or
the other changes that were responsible.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How should multiple (related) projects be arranged (structured) and configured so that they can share code, have a related package structure and enable proper unittesting, and ensuring no namespace collisions ToddLMorgan@gmail.com Python 14 04-21-2006 04:03 PM
Small cameras getting too small? GRL Digital Photography 50 02-03-2006 03:12 AM
Looking for small, impressive 3D-related Python script Kenneth McDonald Python 2 11-29-2005 02:19 PM
C++ Design Principles for Ruby - Classes of Classes. John Carter Ruby 1 08-03-2005 02:02 PM
How should threads be terminated? (related to 'Help with thread related tracebacks') Maxwell Hammer Python 7 06-18-2005 04:20 PM



Advertisments