29
Apr '13

I spend a lot of my time at my day job working on sites that have evolved over the years, with a stream of different coders (all with varying skill and experience levels) and I find that in every codebase the key issues that cause problems are lack of good object oriented code. With procedural code on a complex site you end up with one or more of the these classic issues:

  • Extensive code repetition
  • Masses of functions added to the root namespace
  • An un-navigable set of require/include calls in most scripts
  • Related logic distributed throughout the codebase
  • No realistic way to write proper tests

Recently a client asked me to redesign the way his pricing system works, so that products were grouped by pricing tiers, rather than the complex web of individual prices, offers and calculations coded throughout the codebase. The existing system had long since concerned me as it was very difficult to trace through, there was too much of it hard-coded and the accountability for managing it was on me and my team.

With the go-ahead to redesign this system I created a single new ‘pricing module’, which was simply a class that I could instantiate with a product ID and then use functions within the module to get any and all pricing data that could be needed throughout the site. So now all pricing data that is spat out anywhere in the system come directly from this module, which means all the logic is in one place, it’s easy to read and navigate, it’s fully testable and I feel much more comfortable with being accountable for its correct operation!