Software Engineering: Rebuild and Simplify Complex Decision Blocks - Part 3


This three-part article shows how to rebuild and simplify complex if-then-else decision blocks, using string variables and switch (or case) statements. It will show how the technique works with sample applications built with Google Apps Script, C#, and This technique should work in any language that handles string variables, switch statements, and boolean conditions.

Part one described the problem to solve, the technique to solve it, a sample Google Apps Script to show the solution in action, and the engineering behind that solution.

Part two explained the C# solution and its engineering.

Part three here will describe the solution and its engineering.

Download all the sample software behind this article - Google Apps Script, C#, and - from the GitHub repository.

The Windows desktop solution essentially clones the Google Apps Script solution of part one, adding a CLOSE button

1. application - initial state
to close the application. It has the same

2. application in use
user experience.

The submit button click method at line 106

3. Submit button click method
looks and works almost exactly like the submit button click method described in part twoStarting at line 108, the method declares and initializes four string variables, all of which will potentially become part of the assembled results message. The first four will dynamically match the potential user form picks. The fifth, assembledFlagFormString, will hold the assembled results message string the method will place on the form.

Line 128 declares string variable flagString, which will hold the concatenated boolean values that map to the user responses.

Lines 122 to 125 together declare four string indicator variables. Each maps to the user response at a specific page control. The nested functions map the relevant response values to "0" or "1" string values, so they work as booleans. 

Lines 132 to 135 map the relevant page control states to the boolean indicator flag variablesLine 148 concatenates the indicators into an assembled value for the flagString variable. Because of this, flagString essentially becomes a base-two integer.

Lines 150 to 216 map an if-block to the four relevant page controls. The if-blocks use jQuery to see if the user interacted with its page control. If this interaction happened, the if-block sets the appropriate indicator variable to "1".

At line 214, submitData() uses flagString in the switch statement to build out the assembledFlagFormString variable, with strings mapped to the user form picks. This part also works exactly like the submitData() switch statement described in part two and it includes all the advantages. At the end of the method, line 220 places the variable value in control RTB2 (Rich Textbox 2).

In the application, groups of "similar" form controls have identical behavior, just like those in the C# application. To simplify the code, single procedures handle events for multiple controls when possible. For example, the CB_CheckedChanged event

4. The CB_CheckedChange procedure handles the CheckedChange
event for all the Launch Systems checkboxes
at line 63 handles the CheckedChange event for all the launch system checkboxes. I also used this technique for the radio controls (RB1 to RB5) in the Interplanetary Mission groupbox.

Procedure resetControls() at line 236

5. The resetControls() procedure
resets all controls and removes the user response table from the page.

Part 3 here showed how the demo application works. As we saw, the described technique works in three very different languages and it should work in any language that handles string variables, switch statements, and boolean conditions. With it, developers can focus on the solutions they want to build instead of dealing with nasty, nested if-statements.