I am maintaining a custom built and highly OO e-commerce application. The original designer made a few assumptions like:
– there will never be more than 3 types of sales tax (state, national & hamonized)
– each type of sales tax can have only one rate.
– each state will be assigned one of the three tax types.
He should have known better, but I guess it seemed reasonable at the time… All of a sudden each state is settings its own “harmonized” tax rate.
Problem: 3 levels down the object stack, I have a tax calculation method that uses only amount and tax type. Now I am faced with the task of a pretty big restructure of a application that I have little understanding or little budget to learn
I am inclined to stuff the state code into a session value and do a bit of hard-coded calculations on the other end. (1 day) instead of a re-structure (1-2 weeks??)
Is it my imagination or do OO applications have a bigger learning curve and can be harder to maintain when the business rules take an unexpected turn?
Somewhat. I consider the curve to be steeper, but much shorter than an app built in functional code. An OO app is more likely to follow patterns, adhere to some kind of coding standard, and add structure or a framework to an application. While functional code is much more free to do as it pleases so long as the end-result is a working product. This produces an environment ripe for developer(s) to circum to the spaghetti-code mentality.
Depends. But this could be true regardless of the coding style used. In your case, this would appear true. However, OOP and patterns, historically, have made it easier for experienced programmers to maintain an application vs one written entirely of spaghetti, functional, code.