Structural Analysis Notes

Updated 7/14/2005

Nested Block Proliferation Claims

Although I have indeed encountered p/r code that was a mess of nested IF and/or CASE statements, in the vast majority of cases it was do to poor programming or poor design and was not an inherent fault of the paradigms involved. The most common error is the lack of basic repetition factoring. The second most common reason was failure to break a big routine into smaller routines.

However, even with basic repairs, sometimes there is indeed still some unpleasant nesting of IF statements. One such pattern is combinatorial explosions of dispatching. But, I don't see how OOP is the solution to such cases.

For an example, let's look at the employee classification example again. To keep the example simple, we will look at three Boolean attributes: manager/non-manager, exempt/non-exempt, and part-time/full-time.

The various combinations of these attributes may result in code that looks something like this:

  sub calcPay(emp)    // Calculate pay subroutine
    if emp.isManager     // field reference
       if emp.isExempt
          if emp.isPartTime
             foo_1
          else
             foo_2
          end if
       else  // non-exempt
          if emp.isPartTime
             foo_3
          else
             foo_4
          end if
       end if
    else   // non-mgr
       if emp.isExempt
          if emp.isPartTime
             foo_5
          else
             foo_6
          end if
       else  // non-exempt
          if emp.isPartTime
             foo_7
          else
             foo_8
          end if
       end if
    end if
  end sub

Variations of this structure are not uncommon. Thus the question: how does one "fix" it?

One approach is to convert every IF block into a separate subroutine.

  sub calcPay()
    if emp.isManager
       doManager()
    else   // non-mgr
       doNonManager()
    end if
  end sub
  //-----------------
  sub doManager()
    if emp.isExempt
       doMgrExempt()
    else  // non-exempt
       doMgrNonExempt()
    end if
  end sub
  //-----------------
  sub doMgrExempt()
    if emp.isPartTime
       foo_1
    else
       foo_2
    end if
  end sub
  //-----------------
  sub doMgrNonExempt()
    if emp.isPartTime
       foo_3
    else
       foo_4
    end if
  end sub
  // etc.....

Note that it is assumed that the "emp" table or result-set handle has been made into a regional-scoped variable so that we don't have to keep passing it as a parameter. If and how different procedural languages support regional variables varies greatly.

I do not see how OO techniques solve this dilemma either. The problem can best be described in my opinion as a hyper-cube or hyper-grid where each axis is the aspect or trait that affects the selection of the appropriate behavior (cell). In this example we would have a cube with a manager/non-manager axis (X), an exempt/non-exempt axis (Y), and a part-time/full-time axis (Z).

Although our example uses only Boolean traits, often there may be several mutually exclusive traits (A.k.a. "strategies") per aspect. For example, perhaps instead of full-time/part-time, the labor laws may divide employees into full-time (40 hours), major-part-time (21 to 39 hours), and minor-part-time (less than 21 hours). In that case, one would perhaps use nested case statements instead of nested IF's. We are still going to use the Boolean version for most examples after this diagram.

The first approach presents us with the sticky issue of managing multiple dimensions in what is essentially one-dimensional (linear) programming code. I don't see any easy way out of this one in the code domain. OOP is still linear code.

One technique is to either not use program code, or find better ways to browse or view the code. One browsing approach is to convert the structure into a hierarchy, and then use a tree-browser. However, since the real structure is not a hierarchy, this is kind of artificial in my opinion, and our original approach (nested IF's) already is a tree structure of sorts. (One can also envision a "block browser" that would give us a tree-view or collapsible outline view of our original approach. I don't see such if/case browsers in code editors very often, but I see nothing that precludes their existence.)

My favorite is to use a relational table browser and a form of control table to manage the structure. You would have one column per aspect. You can see some examples in the multiple dispatch section of the p/r patterns page. Putting the information into a table allows us to perform all kinds of view and query acrobatics to find and view exactly the cells that we want to.

     Mgr  Exempt  Part-time   Implementation
     
      Y     Y        Y        [.....]
      Y     Y        N        [.....]
      Y     N        Y        [.....]
      Y     N        N        [.....]
      N     Y        Y        [.....]
      N     Y        N        [.....]
      N     N        Y        [.....]
      N     N        N        [.....]

But, the layout of such a table does suggest an alternate coding arrangement:

  sub calcPay(emp)
    var mgt = emp.isManager   // make some short-cut variables
    var exempt = emp.isExempt
    var part = emp.isPartTime

    if mgt and exempt and part
       foo_1
    end if
    if mgt and exempt and not part
       foo_2
    end if
    if mgt and not exempt and part
       foo_3
    end if
    if mgt and not exempt and not part
       foo_4
    end if
    if not mgt and exempt and part
       foo_5
    end if
    .....etc.....
  end sub

Note how we used local variables to simplify our condition statements. This technique can greatly help readability. Often times programmers will repeat a long data access expression or some other long expression over and over again, making the structure look more frightening that it actually is. Basic factoring like this for repeated structures and phrases can often clean up code considerably.

One downside is that this approach is not as efficient because every condition of every block must be evaluated.

Now on to the issue of simplifying the selection process. Often times there is a pattern to the structure such that large chunks can use a default value or default behavior. If the pattern of defaults or repeats fits a simple geometry in the hyper-grid, then our first approach can often handle it nicely. For example, if all managers had the same calculation, then the first half of our original example may resemble:

sub calcPay(emp)
    if emp.isManager     
       foo_mgr
    else   // non-mgr
       if emp.isExempt
          if emp.isPartTime
             foo_5
          else
             ....etc....

Overall, there are plenty of procedural/relational options to deal with combinational dispatch. I will not say which is best because it may be subjective and depend on the nature of the particular problem domain. However, if deeply-nested IF blocks bother you, there are multiple remedies along with their various side-effects.

I do not see how OOP offers any magic solution to this problem type in general. Sub-classing is often not appropriate because the structure is not really a tree. Picking one aspect as the sub-class division criteria may reduce the nesting level by one, but that is more or less what our second procedural solution is capable of. (We did not have to turn all blocks into subroutines in our example.)

Another problem with sub-classing is that you risk artificially elevating the status of one of the aspects by sub-classing it and not others. If the labor laws change, for example, then the criteria that the sub-classing depended on my suddenly disappear, rendering a lot of your code useless.

As far as I know, all of the non-sub-classing OOP solutions resemble the procedural/relational solutions already shown above.

Some suggested using an Expert System for the situations where there are a bunch of relatively independent rules. However, this may only work well if a major portion or cleanly-divided sections fit the pattern. In many cases the pattern is intermixed with more conventional patterns, making it harder to use a dedicated Expert System engine. See also Game Example under Challenges.

Pre-Calculated Type?

They also suggested that such a type-code could be used for other calculations. However, in my experience a non-trivial "taxonomy" used for one task rarely matches that needed by another task. Philosophers have generally discovered that taxonomies are relative, and this fits my experience also. Further, the uniformity needed for typing is often lacking.

Lack of Uniformity

  if factorA
    if factorB
      blah1
    else // not B
      if factorC
        if factorD 
          if factorE
            blah2
          else
            blah3
            if factorG
              blah4
            else
              blah5
            end if
          end if
        else  // not D
          blah6
        end if
      else // not C
        blah7
      end if
    end if
  else // not A
    if factorH
      if factorI
        blah8
      else
        if factorD  // note repeat usage of factor
          blah9
        else
          blah10
        end if
      end if
    else // not H
      blah11
    end if
  end if

If we plot the active versus non-active combinations of factors, our hyper-grid may resemble:

I am not suggesting that one entirely ignore soft patterns in their code; only that they not over-rely on them, which is what polymorphism does. Polymorphism will elevate a soft pattern into something formal and code-intensive such that undoing it or rearranging it is labor-intensive and error-prone.

General Pattern

• There are often interweaving factors involved in algorithm dispatching. These factors are often orthogonal or semi-orthogonal to each other.

• In practice such conditionals often lack uniformity. Some sections may be shallow, and others deep, for example. This lack of uniformity is the main reason template-based or meta-structures cannot be readily applied to significantly clean up code.

• The "condition tree" (nested if/case statements) that dispatches behavior in a given task tends not to be consistent from task-to-task (under decent designs). Each task will have a different condition tree. There are often some similarities, but it is rarely identical, at least over the long-run. (If it is identical over the long run, then it is often a sign that some other arrangement is warranted.)

I think interweaving orthogonal factors is the biggest cause of hard-to-manage complexity in the real world. You cannot simply isolate factors into modules, objects, etc. that only handle that particular factor. To get real functionality, the interaction between these factors needs to be specified. Custom business software is heavily tied to such relationship management. This is probably because anything that can be nicely packaged into one spot would become an off-the-shelf package or library. Left over after this, is the nitty gritty relationship connections.

Security Access Example

When anything starts to be replicated all over the place, it is time to do some serious re-study of the design. Often such a thing can be factored together somewhere, or at least simplified somehow.

However, sometimes it is unavoidable because there are two (or more) strongly competing aspects. Thus, you have to pull one aspect together at the expense of another.

OO does NOT fix this. Some OO proponents have agreed with me on this. They just claim that their compromise on this issue is better than a procedural/relational compromise (by authoritarian reasoning only so far).

For security access program code, you might have to check to see if the user is authorized for a particular operation (or sometimes entity access).

One might have code like:

  if hasAccess(userRef, "billing") then ....

  if hasAccess(userRef, "billing", "change") then ....

If you see these all over, then you might start thinking, "I wonder if I can bring this all together into one spot or collection?"

You can. However, you would probably have to bring what they act on together also. That is not likely desirable. Diverse things may need security, and we would not want to bring them together just because they happen to use security.

One might be able to subclass things based on their security needs in a language that supports multiple-inheritance, but the code needed for each unit is not likely to be significantly smaller than an IF statement. It might also introduce granularity problems if the class or method is not a fine-grained enough unit to package security needs around. A unit size tuned to one aspect may not necessarily be the ideal unit for another aspect.

Thus, managing multiple aspects is going to be a sticky problem in both paradigms. The best I can suggest is to design the API's with great care to make them as flexible, yet non-intrusive as possible. For example, rather than having:

  if Not hasAccess(userRef, "billing") then
     raiseErr("Sorry, you do not have access to billing")
  else
     [regular stuff]....
  end if

  if hasAccess(userRef, "billing") then
     [regular stuff]....
  end if

That way you don't have to repeat the message display code all over.

Perhaps have an optional named-parameter switch to turn off the message if you wish to handle it yourself. This is kind of a p/r version of "overriding" the message.

if Not hasAccess(userRef, "billing", message=off) then
   raiseErr("Sorry, you do not have access to billing")   // custom message
....  

OR

if Not hasAccess(userRef, "billing", #noMsg) ....   // 'L' dialect

Also note that providing a user reference may be redundant in some setups. The access routine(s) can perhaps find out the current user on their own. Thus, we may be able to reduce the number of parameters.

Why Case Statements Don't Repeat Often

The main reason is that there is usually a weak one-to-one correspondence between the execution choices and subclasses or subtypes. I have been saying over and over that business objects divide poorly into subtypes for the most part. Lack of case symmetry is yet another manifestation of this.

Put another way, the choices available per "task" tend to be different for each task. If we mapped this pattern onto the famous shapes example, (chosen for familiarity instead of realism) it would resemble:

  sub draw(sh)
     select on sh.approach1   // field of sh
     case A
       ...
     case B
       ...
     otherwise
       ...  // default
     end select
  end sub

  sub rotate(sh)
     select on sh.approach2
     case C
       ...
     case D
       ...
     case E
       ...
     end select

  end sub

  sub findCenter(sh)
     select on sh.approach3
     case F
       ...
     case G
       ...
     otherwise
       ...  // default (aka inheritance)
     end select
  end sub

  sub draw(sh)
     select on sh.type  
     case A
       ...
     case B
       ...
     case C
       ...  
     end select
  end sub

  sub rotate(sh)
     select on sh.type
     case A
       ...
     case B
       ...
     case C
       ...
     end select
  end sub

  sub findCenter(sh)
     select on sh.type
     case A
       ...
     case B
       ...
     case C
       ... 
     end select
  end sub

  sub draw(sh)
     select on sh.type
     case "polygon"
       ...
     case "circle"
       ...
     case "rectangle"
       ...
     end select
  end sub

  sub rotate(sh)
     select on sh.type
     case "polygon"
       ...
     case "circle"
       ...
     case "rectangle"
       ...
     end select
  end sub

  sub findCenter(sh)
     select on sh.type
     case "polygon"
       ...
     case "circle"
       ...
     case "rectangle"
       ...
     end select
  end sub

The selector fields can be called strategies after the GOF pattern of the same name. Sometimes they are simple Boolean flags, sometimes names, such as "quarterly", "yearly", etc., and sometimes ID numbers of strategies. (Whether to use names or numeric ID's depends on many factors, and will not be covered here. We use mostly names here for readability of examples.)

Countries Example

  // Procedural
  sub calcSalesTax(sale)
     select on sale.country  // field of 'sale'
     case "Mexico" {...}
     case "China" {...}
     case "Germany" {...}
     ...
     otherwise {raiseErr("missing country!")}
     end select
  end sub
  sub calcEmpTax(emp)   // Employee tax
     select on emp.country
     case "Mexico" {...}
     case "China" {...}
     case "Germany" {...}
     ...
     otherwise {raiseErr("missing country!")}
     end select
  end sub

  // OOP
  class Country abstract
     method calcSalesTax() {}   // interface templates only
     method calcEmpTax() {}
  end class
  class Mexico inherits Country
     method calcSalesTax() {...}
     method calcEmpTax() {...}
  end class
  class China inherits Country
     method calcSalesTax() {...}
     method calcEmpTax() {...}
  end class
  class Germany inherits Country
     method calcSalesTax() {...}
     method calcEmpTax() {...}
  end class
  ...

Viewing it their way, it perhaps may be one of those rare cases where OO would do a slightly better job because of the symmetry of case lists.

However, after thinking about it, the symmetry and one-operation-per-type model may not hold much water after all. First, some countries may have such rare sales with our company that writing tax calculation code may not be worth it. Thus, they may have a quick estimation approach, and then a manual calculation at the end of each year. The estimation strategy may be a simple percentage and shared with other rare buyers.

Second, rather than manually write and maintain code for zillions of countries, a firm may choose instead to farm the calculations off to regional specialists. For example, they may hire a French firm to calculate all European taxes and a Tai firm to calculate all Asian taxes. The calculations then become strategy selectors instead of a dedicated code segment per country. Each country would have the name or code of the strategy in a corresponding Country table field.

The contracted firms that do the employee taxes may also be different firms than those that do the sales taxes. Thus, their strategy (case) lists may be different. Having different strategy lists for different aspects is quite common in my experience. (This would also make factoring into TaxCalculator subclasses more difficult.)

  sub calcEmpTax(emp)
    select on emp.empTaxStrategy
    case "emp_firm_1" {....}
    case "emp_firm_2" {....}
    case "emp_firm_3" {....}
    otherwise {raiseErr("no such strategy")}
    end select
  end sub

  sub calcSalesTax(x)
    select on x.salesTaxStrategy
    case "s_firm_2" {....}   // the only shared firm for both
    case "s_firm_4" {....}
    case "s_firm_5" {....}
    case "s_firm_6" {....}
    case "s_estimate_1" {....}
    otherwise {....}
    end select
  end sub

Finally, even if there are no strategies, if we look at the "forget duplicate" patterns that OO books often dwell on when bashing case statements, the benefits are not so clear cut. (It is said that if you add a new country, you might forget to add the country name to one of the case lists.) In reality, one would put every known country into the list so that they don't have to keep updating if new ones come on line frequently. (In our example we have only two lists, one for CalcSalesTaxes and the other for CalcEmpTaxes.)

Note that this example does not show the relational "joins" to the Country table. Both tax strategy names would be in the Country table most likely.

In the OO versions one may have to remember to add all methods for each country. If a new method comes along, then even existing countries may need the new method. Thus, a programmer may have to visit about 250 subclasses to add the new method. Visiting 250 subclasses is obviously a lot more work than visiting 2 subroutines. (Sure, a fancy IDE may automate some of this, but p/r tasks are not immune to automation.)

It is true that some OO languages can potentially warn a programmer at compile time that an implementation is missing. However, you waive your ability to have defaults if you do this, and this ability is language dependant.

Some OO fans claim that they have seen frequent p/r code with lots of duplicate case statements. Without inspecting actual code, it is hard to see if they were justified. It just may be bad p/r code. Bad code can be found in any paradigm. Often the problem is insufficient use of tables. Sometimes the programmer just is not use to using tables properly, or the particular language and/or API's make tables a pain.

The bottom line is that such a one-to-one repeated pattern is rare in my experience. For that OO-book pattern to occur and be worse to p/r updates than to OO updates (such as new methods), these would have to be true at the same time:

1. Multiple duplicate case lists
2. Few or no shared implementations for list items
3. Frequent additions to list but rare additions of new operations (methods)

I applaud that OO fan's creativity for dreaming up an example that almost fits the case-bashing pattern in OO books, but this amazing effort still has some "reality holes", like many of the bashing efforts in OO examples. Even if the pattern occurs say one percent of the time, adding OO just to handle those cases flunks the Blue Moon Principle, which basically states, "spend complexity on the common stuff, not the rare stuff".

Tablized Version of Country Taxes

We could have the case statement call separate subroutines, but some complain that this requires two routines to need re-compiling instead of one when a country is added. Note that we could also make the naming be automatic by having the routines be named something like "SalesTaxCountryX" where X is the country ID. In that case we would not need specific fields for the routine names since the name would be automatically generated. I am not showing that approach here. I will leave it as a reader exercise.

One might also claim that adding a new country requires two places to be updated in the table version versus one in the OOP version. However, the tabled version makes it easier to view, list, and query the country table/info. To get the same functionality out of the OOP version, some sort of collection would have to be constructed. This may also require two lists, depending on the OOP language. In the future, the tax program code may actually be stored in the table itself, disarming such criticism all-together. However, such practice is not yet acceptable, partly because infrastructures, such as IDE's don't currently recognize this practice.

  Table: Countries
  ----------------
  countryID    (int)
  countryName  (string)
  SalesTaxRoutine  (string)
  EmpTaxRoutine    (string)
  isActive     (yes/no)
  etc....

  sub calcSalesTax(rs)         // rs = recordSet
     var callme = trim(rs.SalesTaxRoutine)
     append(callme, "(rs)")    // append parameter
     if not eval(callme)       // assume returns status indic.
         errRaise("Error calling " & callme)
     end if
  end sub

Dispatching Issues

For the sake of comparison, I will assume putting the country-specific code inside the Country table itself. Chuck (an alias) claimed that I had to do a record look-up to get the Country-specific code and that he didn't. Although technically true, he still has to do a record lookup, as will be described. I am just piggybacking on that lookup since it is a necessary step in both designs (paradigms).

Unless he stores all country information[1] in code (classes), his version has to query the Country table also. Chuck had code in the parent class and one or two lines in each country sub-class to map the sub-class to an "external storage" such as a RDBMS. (He used a "country ID" as the key.)

I claimed that such mapping code is roughly equivalent to my table (and code) lookup. He disagreed, but mostly via the definition of "dispatching", which excludes data lookups in his opinion. To me this is splitting hairs of words.

Since we are comparing apples to oranges, I suggested that we compare the overall maintenance effort of each design instead of trying to say this section of code is equivalent to that section. Looking at the final counts washes out part-to-part comparisons which can get hairy and testy otherwise. In other words, the final effort count is a cleaner metric. Overall, the OO solution is not less code and not less measurable maintenance.

One problem with his design is that he has two similar structures that have to change in lock-step when new countries are added. He has country sub-classes that mirror the Country table rows. In my opinion, this is a violation of the single choice principle. He disagreed in that duplication is sometimes needed as an interface layer, which is what he called his mapping code. He claimed that this was the tradeoff paid to decouple his code from a relational model (if something else is later needed). In my opinion that is not worth it unless better competitors to relational databases gain market share. Preparing to decouple from relational is like planning the decoupling from the OO model, in my opinion.

[1] Chuck also disagreed about the likely-hood of needing more country information besides just the tax methods. In my opinion, having more info being attached to such tables is common. For example, the country name and an "isActive" flag can be stored in this table. These can be changed without programmer intervention if they come from the table instead of sub-classes. Storing attributes in program code is often limiting in this way. It might be good job security for programmers, but bad design otherwise. Some argue that languages such as Smalltalk make it easier for attributes to be dynamically changed. However, this tends to limit the access of data to just Smalltalk. Smalltalk is not a full-blown database, and treating it like it is may result in continuity problems if one later switches to a real database system.

Chuck also claimed that my "program code in table" approach is really "OO". See the top section of "P/R Patterns" for a discussion on this issue.

In addition, Chuck said that his approach can have more compile-time checking. I tentatively agree, but perhaps at the expense of needing a re-compile or re-bind per new country.

Another Dispatching Approach - "Calculated Scripts"

  sub countryOperation(countryID, operationID) {
    scriptFileName = countryID & '_' & operationID & '.prg';
    execute(fileAsText(scriptFileName));
  }

Case Statement De-Casing

For example, the choices may grow no longer mutually exclusive, and thus become IF statements. Procedural code usually allows the criteria for the different case or IF blocks to change without having to move code around to different classes. Only the IF criteria changes. See polymorphism notes for more on polyUNmorphism.