Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Conditions based on keys

Status
Not open for further replies.

dragonwell

Programmer
Oct 21, 2002
863
US
I've been running into this design issue, and I'm sure it's a common one. Just wondering how you have handled it, or if there is a pattern that can be applied.


In my code I need to conditionally execute code based on a variable's value. Ideally, of course, we would test only boolean types. In the case where there are more than true/false values to test we sometimes use switches but even you need to have some idea of what the case values could be.

For example, my Employee class has a Status property. Status is an integer value, such as 1 = active, 2= on leave, 3=dismissed, etc. These values are stored in a Status table of the database, and the Employee table has a status column of type integer to identify exactly one status id per employee. So now when my Employee object is instantiated, it gets it's Status property from the database.

The program eventually needs to follow different execution paths depending on the Status of the employee.

ie
Code:
if(myEmployee.Status != 1)
{
    //...
}

But what I don't want to do is hard code these values into the code. It always seems that at some point, the code needs to know what the values are.

Even worse, I have run into cases where primary keys are used to enumerate permanent values such as in the employee/status example. What if a row is accidentally deleted and a new one put back in? The "Active" could end up with status id of 6, and the code is broken.

I have thought about hard-coding an enumaration (based on int values) into the code, but ideally these values should be editable by the administrator.

I am now coding in .net and I am thinking the solution is somehow tied into the app.config system, but I have not really thought that through yet.

Please comment.

Best regards to all,

David
[pipe]



 
Ok...

Thanks, Pete. I am struggling to see how to apply this to my problem, but I will keep at it!

Any more ideas?

Thanks,
David
[pipe]
 
So the implementation once you created the pattern would look like this:
Code:
MyCommand cmd = PayrollCommands.getCommand(myEmployee.Status);
cmd.execute();

no if nor case statements. Also in Java you can use your own ClassLoader and build a command system where commands can be added in binary artifacts to the application. does that help?


-pete
 
I think so. Really a different way of approaching this. I guess I was thinking more of implementing some sort of "auto-configuration" system, where during application start-up the constants are read in from the database. Is that bad? From what I can tell about the Command pattern, you STILL have to define what the values the commands are based on, right?

in this
Code:
getCommand(myEmployee.Status)

somewhere in there, the value of Status needs to be compared to a set value.

Sorry if I'm being dense!

I do appreciate your time,

David
[pipe]

 
This type of subject is not suited to message based discussion but lets keep trying until you have had enough? :)

>> during application start-up the constants are read in
>> from the database. Is that bad?

Not necessarily but lets look at it. What do you get by defining the constants externally from the code? You still have to write specific code to execute upon a value matching the constant obtained from the database right?

If( employee.status == icamefromdatabase2) doOption2();

So if you later add a row to the database containing a 3 for the constant value you would have to add some code the application like this:

If( employee.status == icamefromdatabase3) doOption3();


Having to alter code when you add a new row to a database is not the mark of a good design. If I have misunderstood your point about the value in the database please try to explain it.

The command pattern is only a replacement for the if() or switch() technique that is frequently abused. As far as I can tell so far it is not connected to any desire to contain these values in a database, nor are the if() statements you previously posted right?

Instead of adding an if() statement, the Command Pattern is preferred. Each Command class defines it’s own value so instead of having to change the existing code you just create a new class with the value and behavior and plug it into the application without having to alter any existing code. No ripple effect. As I mentioned before, in some environments, like Java (and most others), you can extend this behavior all the way out to binary components. Meaning that you don’t even need to re-build the pre-existing application/components.


-pete
 
My first thought is: You have organized it neatly in the database, why not do that in in the object model?

I mean, you have a separate employee table and a separate status table. Why not have an Employee class and an EmployeeStatus class? You could then move all the decisions based on the status to the EmployeeStatus class. The next step is to divide the EmployeeStatus in "on leave", "active", etc. subclasses. Then a factory method gets the value from the database and creates the right subclass for you.

Best regards
 
Thanks!

>>Having to alter code when you add a new row to a database is not the mark of a good design.

That statement sums up the problem exactly!

I can see how both the factory method and command patterns make it so you don't have to ALTER code, but you are still ADDING code when a new condition comes along. I guess I can live with that for now.

>>This type of subject is not suited to message based discussion but lets keep trying until you have had enough?

Huh? Ok! I guess that's enough for now :)

David
[pipe]

 
David
>> Huh?

I mean like using a whiteboard and a live conversation would be a significant improvment.



-pete
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top