Alternative option to multiple conditionals

[DCW]

Greetings:

Recently I was asked to refactor a method that establishes some default
values for an insurance policy. In looking thru the method, I noticed the
original developer had used multiple conditional if/case statements that were
nested many levels deep to accomplish this goal. I am trying to determine
some alternatives since it is really hard to understand and maintain. I know
that this is really a business rules engine and there are many options in
terms of software and methodology (RETE algorithm, 3rd party rules engines,
etc..) but these aren't practical based on the business and design decisions.


I'm hoping the group can suggest some alternatives. Here are a couple of
things I've considered so far:

1) A class factory pattern that takes the initial inputs and returns an
interface with an 'Apply' method. Although this might break up the
conditionals, they would still need to be applied in the implementation
class. Granted, it would be easier to maintain but I'm not convinced this is
the right way to go just yet...

2) Using a delegation pattern to take specific action on the default values.
EX: Declaring default delegate methods that apply the standard default and
offering the user the option provide his own delegate to override the
behavior. I don't really like this option as it forces the person
implementing the method to have specific knowledge about the internals
(albeit masked via delegation) and I've really just pushed the coditional
statements to the callign context.

3) A truth table to capture all possible conditions and then selecting out
of that to apply defaults. What I don't like here is that the process could
be resetting the same value repeatedly (based on the downstream conditions
changing). Also, this will require sequence to become paramount because if a
field is changed more than once, the last value has to be the correct value.
This makes changing the method difficult later.

Thanking you in advance for any insight you can provide,

--Drew

 

[DCW]

Alvin:

Thanks for the reply and I do agree that keeping this simple is a huge
consideration. However, there is another reason why I am considering moving
to another approach than just simply reusing or commenting the existing code.


If you have ever worked in insurance (I haven't - first insurance contract
in 15 years as a contractor - just lucky until now I guess), you are
probably aware of the various state regulations that differ dramatically
state-to-state. In short, each state might have a different set of default
values or different dependency conditions, etc... This sometimes requires a
different UI or different middle tier or both to address these concerns when
saving or working with an insurance policy.

To handle this on the UI side, we are using the MVP versus the MVC pattern
and each state potentially has a different presenter/viewer based on the
version (read:state). The issue here is that the method that sets the states
needs to be version-aware as well. If I just copy and complete his code (he
is already at 1500 lines and about 20% complete for 1 version out of 26),
I'll have to do this for each version (state) that is brought online. And,
somewhere in this mess, I'll need to change the conditionals to reflect the
different regulations, modify their downstream logical branches and you just
know this will be hard to debug and alter as state regs change.

For what it's worth, Microsoft is running this project (I am contracted to
them for the length of the engagement) and our MS project lead doesn't really
know how to handle this either. His advice was to post here to see what
others might recommend.

Thanks,

Drew

 

[DCW]

Thanks Alvin -- the XML approach is probably a good way to solve this issue.
WF has always appealed to me but I don't think we can get management to sign
off on it because they are already so late in the game (and failing, which is
why they brought in the MS consultants - basically, there was no discovery,
design, analysis, etc... they just went straight to build).

Thanks again,

--Drew