0

I'm performing a re-write of an application to be dependent upon Table Driven methodologies. The candidate application processes events through conditional logic. The rewrite will remove hard-coded event dependence in favor of decision making via a database table whose columns are configured for Boolean selection of specific details for each event.

My concern with this implementation is behavior madness. I may need to create many methods to directly call the functionality that was once conditionally logic dependent. They may be large in number and what I would to avoid are the following situations:

  1. Large, primary function with many little helpers
  2. Smaller, isolated functions with a smaller number of helpers
  3. As many functions as needed with no regard to number

The table methodology is rigid and inflexible within this implementation. A stair-step approach to method design is a consideration and the rewrite is dealing with about 200 or so events total.

Should there be a concern with the number of methods based upon my implementation? I intend to read the table into memory and process events. I am familiar with this and want to be certain my implementation adheres to proper coding standards and guidelines.

Community
  • 1
  • 1
Mushy
  • 2,535
  • 10
  • 33
  • 54
  • Ideally there should really be as many simple functions as required, so as long as they don't bleed into each others' domain they can be called and tested independently of each other. – M. Prokhorov Mar 14 '17 at 18:53
  • Another alternative would be a Rete rules engine like Drools. Both decision table and rules engine solutions can get out of hand when the number of rules/decisions gets too big. – duffymo Mar 14 '17 at 18:54

0 Answers0