Any design patterns/coding methods for complex logic?

Question

I had to clean up code for an online college application. There's nothing particularly wrong with it, but it was complicated. Different degree programs had different prequisites, fees, required documentation, and questions. On top of that, students coming from the military get different fees, and previous students pay no fees and skip steps.

Obviously all this logic can get pretty complex - and cause bugs. I'm wondering if there's a design pattern or coding method that would help with organizing the logic. I'm using PHP, not that it matters.

The strategy pattern seems to have the most potential, but it seems to me I'd need strategies on top of strategies for this.

I imagine the field of "Business Logic" might cover this at least partially, but searches haven't turned up indications of any elegant coding methods to use.

Answer 1

I think a combination of patterns would be helpful. Fowler's Domain Model pattern aims to tame complex domain logic. Using a Layered architectural pattern is another option, as described in POSA1. Strategy pattern also seems to be a good idea for defining a family of related algorithms.

Answer 2

As a starting point, have you come across unit testing? A quick google for PHP unit testing came up with http://www.phpunit.de/.

As a starting point you should look to see if you can unit test your existing code. That way you have confidence that it does what it's meant to and should be able to make changes in the future without worrying so much about breaking existing logic. Also once you've got unit tests in place on existing code you can beging to make changes to improve the logic with same level of confidence.

Answer 3

Applying some design patterns won't solve all of your problems, though some may help to better organize the code. If you want to reduce bugs, then implement some sort of automated testing, look at the Test Driven Development and Continuous Integration methodologies.

Answer 4

Stategy pattern, as you suggest, sounds like it might fit the bill well - but with a fair bit of complex logic you'll want to put this in a domain model, and not the transaction script you're probably using now.

Fowler's book Patterns of Enterprise Application Architecture has good explanations of this whole area of thinking about your app (he suggests you start with that and work from there).

And as others have said, unit testing always helps!

Answer 5

I'm not convinced that this kind of problem is addressed by a pattern or patterns as such. To some extent is "just design" - you build a design and discover relationships and flex points where OO techniques (for example) help and at that point patterns come into play.

I've observed over the years many attempts to solve these kinds of problems by "Not Writing Code". That is we find some way to externalise the business logic into something more malleable than code. So it might just be that you externalise the fee rules:

  Thinking 101  Standard $100   Alumni $50   Ex-Military $0
  Hard Sums     Standard $500   Alumni $100  Ex-Military $0

Now changes in these rules are a config change rather than a code change. This kind of data-driven appraoch is probably better than code.

Then you want to externalise logic, and so Rules Engines emerge.

And externalise processing logic and hence we get BPEL.

I see success with all these approaches, but ... in effect you have logic externalised somewhere so two issues remain:

1. How readily can you test this logic? You probably have not reduced the amount of required testing.
2. How readily can you manage the life-cycle of this externalised logic? Can you trial it, for a perhaps a small customer population, roll it back when it's found to be wrong? Allow multiple versions to be live at the same time?

This stuff is still software, it really is code in disguise.