2

The source code I'm working on at the moment performs numeric calculations between a bunch of different properties belonging to different data models. All the calculations are coded in a big method with a lot of If statements than make it very complex, difficult to change and it contains some bugs.

I have not found a design pattern that fits into this problem that I think is very common in any financial application. Any help with this?

The source code is c# with .NET fw 4.

7
  • 2
    What is the actual problem you have? Asking for a design pattern without a description of the problem is like saying "there is something wrong in my basement, which hammer should I use?"
    – user40980
    Jun 2, 2013 at 17:37
  • 2
    Indeed. The only pattern I can think of is function composition (instead of a bunch of equal operations, make a chain and each op only cares about 2 models). More likely is simple design fixes to reduce the number of different data models via aggregation, abstraction or encapsulation.
    – Telastyn
    Jun 2, 2013 at 17:40
  • The actual problem is that I have a lot of fields in three different models and when a field change, depending on the value of another field, a calculation must be performed. This is implemented in a huge switch-case with a lot of If statements. I do not think that is the best implementation ever. An example is, when changing the amount AmtChg, If the indicator PctInd is set to P, the amount AmtCalc must change, if PctInd is A then calculate PctCalc. Jun 2, 2013 at 19:34
  • In that case the "Automate dependency tracking" series by Michael Perry may be of interest to you. He uses Java, but the principles should be applicable in C# as well. Jun 2, 2013 at 19:58
  • @user2214951: it would be helpful if you could tell us more about the order of magnitudes of your problem. How many LOC has your method? 50? 500? 5000? How many attributes of your data models are involved in that calculation? 10? 100? 1000?
    – Doc Brown
    Jun 3, 2013 at 19:37

2 Answers 2

1

Well, I don't believe there is a design pattern which can help you here, but maybe some "tactics". Honestly, it is hard to give you a good answer with so few bits of information. Here are my thoughts, based on some guessing how your code may look like:

  • start by refactoring that (too) big method into smaller methods. Make the structure transparent, introduce variables for intermediate results, decouple independent parts of the calculation, make sure the same calculation does not exist redundantly in two places of your source code. Also, introduce data structures for attributes which belong together

  • visualize your data flow (for example, by drawing a data flow diagram). This will help you to understand the dependencies better and probably help you by further refactoring into indenpendent parts or components. It will also help you to understand where you have to change something when a new requirement arises.

  • check if you really need a "push model" for your calculations (a change in one attribute triggers a sequence of calculations, you have to update a lot of intermediate variables, perhaps have to deal with unwanted side effects), or if you can switch to a more functional "pull model" (only when a specific value is needed the related calculations are triggered, calculating all the intermediate results from the current state of your input variables). A "pull model" works like an SQL view in a relational DB, a "push model" like an utility table in a relational database which has to be filled with redundant data.

  • it may be also a good idea to decouple your program from that "3 different data models" by introducing an intermediate layer which gives your calculation code a view upon the data which is suited for its needs. But with so few information how you calculation may look like, I am unsure if thats the right decision in your case, you have to decide that by yourself.

0

Well, something that might be helpful for you is doing Refactor:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring. http://refactoring.com/

There is a book about it.

Anyway. I was in the same situation and I have to do a lot of refactor, like:

Simplifying blocks of if statements in methods doing "Decompose Conditional"

Decompose Conditional You have a complicated conditional (if-then-else) statement. Extract methods from the condition, then part, and else parts.

if (date.before (SUMMER_START) | | date.after( SUMMER_END))
     charge = quantity * _winterRate + _winterServiceCharge; 
else    
     charge = quantity * _summerRate; 

Changed to:

if (notSummer( date))
    charge = winterCharge( quantity);
else
    charge = summerCharge (quantity);

Consolidating conditional expressions in a single method. For example, if I have a bunch of ifs in a method before doing the real job, then I group all those ifs in one single method

Once that you have done some refactor of your code, you realize that is easy move the pices together so at that point I would suggest the Strategy pattern.

In computer programming, the strategy pattern (also known as the policy pattern) is a software design pattern, whereby an algorithm's behaviour can be selected at runtime. http://en.wikipedia.org/wiki/Strategy_pattern

and finally, remove switch statements (if you have them) with some polymorhism.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.