Home > Archive > Software Engineering > October 2006 > Switch statement alternative?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Switch statement alternative?
|
|
|
| Hey all, I need some direction help. I have a switch case statement
that is seemingly my only option right now, but its too large and not
easy to maintain the code. Here goes...
I have part descriptions (ie. 3/8" X ____" NYLON ALL-THREAD RODS...or
____" x ____" X ____" ____ WRAPPED MULLION) that I need to replace the
blank lines on. I do a switch on the part id.
I have 53 in all out of the parts list. What fills the blank is
dependent on information specific to the customized product being
built. Getting the information is not a problem...the problem is that
I cannot do any generalization. Almost every part is different and
what information the blank is based on is different for each part. I
have no generalized function aside from the one that fills the blank.
I just do a switch statement and have specialized business logic code
for each part.
I'm sure you can see the problem...what happens if we change a part
description in the system, or add a new part, or remove one? I have to
change the code. This is not the best practice, but I see no
alternative at the moment. Everything is so freaking customizable
here! Please help, any ideas?
| |
| Richard Harter 2006-10-17, 9:59 pm |
| On 17 Oct 2006 08:22:34 -0700, "Phuff" <pc.huff@gmail.com> wrote:
>Hey all, I need some direction help. I have a switch case statement
>that is seemingly my only option right now, but its too large and not
>easy to maintain the code. Here goes...
>
>I have part descriptions (ie. 3/8" X ____" NYLON ALL-THREAD RODS...or
>____" x ____" X ____" ____ WRAPPED MULLION) that I need to replace the
>blank lines on. I do a switch on the part id.
>
>I have 53 in all out of the parts list. What fills the blank is
>dependent on information specific to the customized product being
>built. Getting the information is not a problem...the problem is that
>I cannot do any generalization. Almost every part is different and
>what information the blank is based on is different for each part. I
>have no generalized function aside from the one that fills the blank.
>I just do a switch statement and have specialized business logic code
>for each part.
>
>I'm sure you can see the problem...what happens if we change a part
>description in the system, or add a new part, or remove one? I have to
>change the code. This is not the best practice, but I see no
>alternative at the moment. Everything is so freaking customizable
>here! Please help, any ideas?
It's a little hard to tell what your options are from your
description. What you might want to do is something like this:
Instead of having the information in code have it in tables that you
read in; the code doesn't have to change, just the tables. This only
solves one part of your problem - you don't have to recode and rebuild
your software. Now what you want to do is to avoid manually changing
the tables all the time. The trick here is to have a separate program
to alter the tables. Your tables are a little database of
information. If you like and find it convenient, use a real database
program.
One other thought: If you find you have a big honking switch it is
often better to replace it with a jump table of some kind.
HTH
| |
|
| Thanks Richard. Sorry for the confusion. My problem is not storing
the data..its stored in a sql server db. I generate a list of parts
for a manufactured product, one that is annoying customizable (at least
from a programmers perspective). Some of the parts have blanks in the
description because that blank (possibly a dimension, or a finish
color) is contingent on the configuration for a job.
For instance:
____" X ____" ____ OUTSIDE CORNER TRIM
This would be some inch x inch color finish variable. Maybe 6 x 3 WEG
(an acronym we use for color finish). Its easy to read the xml file,
get the dimensions and exterior finish of the product and fill in the
blanks. But another part may be dependent on completely seperate
dimensions and other variables. I have 53 parts in total and when
coding up to replace the blanks I need to have separate code for each
part since they are all so different.
My problem is not storing data, is maintainability. I can do a big
switch statement on the part ids and write code that is customized for
each part to replace the blanks and return the description string.
However, if inventory decides to change a part description (maybe we
start getting a part from another supplier) I would possible need to
change the code specific to that part. What if they add a new part to
the database that has contigent descriptions? Well, if I don't want a
designer to have to manually change the description I need add code for
the new part. Parts don't change super often, but they do change and I
want my code to be dynamic and able to handle all parts, not be tied
down to each one. Does this make sense? Let me know if I need to
explain further. I'm presently looking at Decorator design patterns.
Richard Harter wrote:
> On 17 Oct 2006 08:22:34 -0700, "Phuff" <pc.huff@gmail.com> wrote:
>
>
> It's a little hard to tell what your options are from your
> description. What you might want to do is something like this:
> Instead of having the information in code have it in tables that you
> read in; the code doesn't have to change, just the tables. This only
> solves one part of your problem - you don't have to recode and rebuild
> your software. Now what you want to do is to avoid manually changing
> the tables all the time. The trick here is to have a separate program
> to alter the tables. Your tables are a little database of
> information. If you like and find it convenient, use a real database
> program.
>
> One other thought: If you find you have a big honking switch it is
> often better to replace it with a jump table of some kind.
>
> HTH
| |
|
| I just solved my problem. I will replace the blanks in the database
with tokens...%exteriorFin% or %interiorFin% or %wallThick% or
%panelHeight% etc etc. Then I just need to write a simple parser to
replace those tokens instead of generic blanks. thanks!!
Phuff wrote:[color=darkred]
> Thanks Richard. Sorry for the confusion. My problem is not storing
> the data..its stored in a sql server db. I generate a list of parts
> for a manufactured product, one that is annoying customizable (at least
> from a programmers perspective). Some of the parts have blanks in the
> description because that blank (possibly a dimension, or a finish
> color) is contingent on the configuration for a job.
>
> For instance:
> ____" X ____" ____ OUTSIDE CORNER TRIM
>
> This would be some inch x inch color finish variable. Maybe 6 x 3 WEG
> (an acronym we use for color finish). Its easy to read the xml file,
> get the dimensions and exterior finish of the product and fill in the
> blanks. But another part may be dependent on completely seperate
> dimensions and other variables. I have 53 parts in total and when
> coding up to replace the blanks I need to have separate code for each
> part since they are all so different.
>
> My problem is not storing data, is maintainability. I can do a big
> switch statement on the part ids and write code that is customized for
> each part to replace the blanks and return the description string.
> However, if inventory decides to change a part description (maybe we
> start getting a part from another supplier) I would possible need to
> change the code specific to that part. What if they add a new part to
> the database that has contigent descriptions? Well, if I don't want a
> designer to have to manually change the description I need add code for
> the new part. Parts don't change super often, but they do change and I
> want my code to be dynamic and able to handle all parts, not be tied
> down to each one. Does this make sense? Let me know if I need to
> explain further. I'm presently looking at Decorator design patterns.
>
>
> Richard Harter wrote:
| |
| Paul E. Black 2006-10-17, 9:59 pm |
| On Tuesday 17 October 2006 11:22, Phuff wrote:
> ... I have a switch case statement
> that is seemingly my only option right now, but its too large and not
> easy to maintain the code. Here goes...
>
> I have part descriptions (ie. 3/8" X ____" NYLON ALL-THREAD RODS...or
> ____" x ____" X ____" ____ WRAPPED MULLION) that I need to replace the
> blank lines on. I do a switch on the part id.
>
> I have 53 in all out of the parts list. What fills the blank is
> dependent on information specific to the customized product being
> built. ... [I] have specialized business logic code
> for each part.
I suggest a two step process: use a table, then, when that is well
understood, make it a file. Below is an example. The code and data
structures have to be more elaborate than a switch statement, but it's
great when you want to search by size (not part number) or put it in a
file. The table and lookup function can (and should) be in a separate
file (or class if you're one of those OO whippersnappers). Which
brings me to the second step.
Once you're happy with the data structure and the information, you can
write a part information file reader (and checker and editor ...).
When you reach that step, you can change the information file without
touching the code.
The two steps breaks the time to modernize the code into two chunks
and lets you perfect one part (access functions and data structures)
before tackling the parsing, format, checking, etc.
-paul-
--
Paul E. Black (p.black@acm.org)
#define NULL ((char*)0)
typedef struct {
int partno;
// NOTE: these could be an array instead of exactly 3 fields
char *info1;
char *info2;
char *info3;
} partInfo;
static partInfo partTable[] = {
{103425, "32 in", NULL, NULL}, // 3/8" x ____" NYLON ALL-THREAD RODS
{146228, "1/4", "1/4", "12"}, // WRAPPED MULLION
};
static int numberOfParts = sizeof(partTable)/sizeof(*partTable);
static partInfo *lookupPartno(int partNumber)
{
int j;
for (j = 0; j < numberOfParts; j++) {
if (partTable[j].partno == partNumber) {
return &partTable[j];
}
}
return (partInfo*)0;
}
main()
{
printf("There are %d parts\n", numberOfParts);
int partno = 103425;
partInfo *pi = lookupPartno(partno);
// SKIMP - yeah, I don't check for failure (and half a dozen other
// things!) Its an example, for crying out loud.
printf("Part number %d is %s\n", partno, pi->info1);
}
| |
| Richard Harter 2006-10-17, 9:59 pm |
| On 17 Oct 2006 09:51:18 -0700, "Phuff" <pc.huff@gmail.com> wrote:
>I just solved my problem. I will replace the blanks in the database
>with tokens...%exteriorFin% or %interiorFin% or %wallThick% or
>%panelHeight% etc etc. Then I just need to write a simple parser to
>replace those tokens instead of generic blanks. thanks!!
>
Isn't that the way of it? You ask help and the answers you get don't
actually solve your problem. Somehow the answers that don't help
inspire you to come up with a good solution.
| |
|
| Phuff wrote:
> I just solved my problem. I will replace the blanks in the database
> with tokens...%exteriorFin% or %interiorFin% or %wallThick% or
> %panelHeight% etc etc. Then I just need to write a simple parser to
> replace those tokens instead of generic blanks. thanks!!
Tip: Plenty of generic text template systems are already invented for you.
They will solve sticky issues, like what if one of your database fields
naturally contains a %panelHeight%.
--
Phlip
[url]http://www.greencheese.us/Z Land[/url] <-- NOT a blog!!!
| |
| H. S. Lahman 2006-10-18, 10:02 pm |
| Responding to Phuff...
> Hey all, I need some direction help. I have a switch case statement
> that is seemingly my only option right now, but its too large and not
> easy to maintain the code. Here goes...
>
> I have part descriptions (ie. 3/8" X ____" NYLON ALL-THREAD RODS...or
> ____" x ____" X ____" ____ WRAPPED MULLION) that I need to replace the
> blank lines on. I do a switch on the part id.
>
> I have 53 in all out of the parts list. What fills the blank is
> dependent on information specific to the customized product being
> built. Getting the information is not a problem...the problem is that
> I cannot do any generalization. Almost every part is different and
> what information the blank is based on is different for each part. I
> have no generalized function aside from the one that fills the blank.
> I just do a switch statement and have specialized business logic code
> for each part.
There is nothing inherently wrong with a switch statement, but in this
case there are probably better ways to attack the problem.
The first thing I would look at is a lookup table. If the entire text
string needs to be customized you might have the table contain pointers
to functions, one for each part. The part number would be used to index
into the table to invoke the right function.
[Part numbers usually aren't convenient so you might need a second table
to convert the part number to an array index. That would be defined
once externally in a configuration file.]
You indicated in another message that you get the data for the blanks
from an RDB. In that case the lookup table could be multidimensional
where each column was a SQL text string to plug into a query. By
putting a prefix on the table text, you can also provide the
non-variable text strings with minimal parsing. (The first column would
obviously need to be a count of terms if different parts have different
strings.) You now have a single generic method to read the table, form
a SQL string, and construct the text from the returned dataset.
A significant advantage of lookup tables is that they can be defined at
startup from external configuration data. In this case everything is
text strings and all one needs is a mapping to a table index. That
allows one to add/remove parts and even edit their presentation without
touching the code.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
|
|
|
|
|