D
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
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
), you are