What to do about complex business logic based on many options

Question

To preface, I think this problem would be easier to understand if I gave an example: How does a complex tax evaluation application manage multiple tax laws and personal situations?

I inherited a web application which has a lot of business logic lodged in the views. This logic controls page flow and control visualization. The gist of this logic is based on properties of a context such as: what state was the action taken, who is the client, what type of task, and many more. example of such logic:

if task.state == "WA" then goto view1
else if task.type == "Wash Windows" && task.clientid == 5 then goto windowWashview2 

feature requests come in all the time to add new tasks, with new rules. I've explored Domain Specific Languages briefly.

Any suggestions?

Answer 1

First and foremeost, you seriously need to isolate business logic from Views. You don't need to do it all at once, but with new feature requests, you really need to workout a better distribution of roles in your application.

Secondly, Strategy Design Pattern is exactly what you need in your application:

The idea of the pattern is to eliminate hard dependencies and let the components decide what to do with their tasks. For example, you might have a Router class that basing on what state it is, will return the right view to present to the user.

You might have JobBasedCalculator class that would base calculation of the location and job type it supports. And every JobCalculator class should be treated as that, just SOME JobCalculator class regardless if it's an IT job, Civic Job, etc... they should all conform to the same interface is what I mean.

• Another pattern to look at is State Object. Might prove to be useful if you have so many logical decisions to make based on selections, but if app is large, this can be an anti-pattern as well.

Answer 2

I agree with @Alexus , but I would suggest you to first to a graphic options-path tree to plan for what components. Its basically a probability tree by logic conditions that branches into the main options you will need to separate. For example:

'Action' can branch into 'clients' for that action, and then each client can pertain to 'states' and each state then have 'state-tax' .

Once you have all this you can form classes and objects in a way that will allow you to make your pattern more efficient. Yes, i know it sounds obvious, but getting directly to code is bound to make a mess. Or you can try a view first approach and see what you need for each view and then reverse how to get there.