Tuesday, May 19, 2009

Logic

I ran into an interesting challenge today. I had some conditions that needed to be met in order for me to add an item to a drop down box.

Here are the conditions:

1. When ActiveOnly flag is true, then only add items that are active.
2. When ActiveOnly flag is false, add all items.

Ok, I know it seems simple, and it was very easy to write this as an if statement. This is what I started with:

...
if(activeOnly)
{
if(item.IsActive){
dropdown.Items.Add(item.Name);
}
} else {
dropdown.Items.Add(item.Name);
}
...


Ok that gets the job done, but it doesn't look very elegant, and I've repeated my insert code twice.

After looking at this a while, I decided that there had to be a better way to write that code, so I did a classic truth table:


ACTIVE
ONLY -------------
ACTIVE | T | F |
-------------
| T | T |
-------------


Basically indicating to me that the only time that I DON'T want to write a value is when ONLYACTIVE = true AND ACTIVE = false.

At this point this is starting to look like an opportunity for a specification pattern but I'm trying to just get the job done AND I didn't want to over kill it. Thinking in terms of specifications does shed light on how we should think about this test. If the ONLY time we DON'T write a value is when ONLYACTIVE = true AND ACTIVE = false, then shouldn't we TEST to see if this CONDITION is TRUE?

This is the final if statement result:


...
if(!(activeOnly && !item.IsActive)){
dropdown.Items.Add(item.Name);
}
...


Now isn't that less smelly??

No comments: