1. The idea
1.1 Graphical representation of a program
1.2 A flat view ?
1.3 A dead end
1.4 Cheating ?
1.4.1 Adding functionality
1.4.2 Object orientation
1.4.3 Fiddling with function pointers
1.5 Context oriented programming
1.5.1 Sharing information within a level
1.5.2 Calling a function from a lower level
1.5.3 Definition of a level or a tree
2. Building blocks
3. Reusing modules in different context
Top Up
Prec

1.4 Cheating ?

Next Skip

With the design philosophy above, you are often trapped with the hierarchy. You have this report component (a sub-tree) which must be enhanced to print differently depending on some external factors. For example it can print to a printer, a fax or send the report by mail.

There are various way to enhance this report engine:

  • Add the functionality to deal with these new requirements and add a parameter to select the output.
  • Turn it into an object. A good solution, but expensive, see below.
  • Play smart with global variable.
  • Fiddle with function pointer,

In many cases, you will end up with functions passing around information needed by sub-functions. For example, the fax and mail output requires an address, which is behond the scope of the report module. So if we want to play clean, the report module has to accept this new parameter, which is totally un-needed for the report itself so it can pass it down to the output selector which ultimatly will pass it properly to the output module.

Top Up
Prec

Next Skip
One big HTML document