Business rules change and you will need a way to accommodate that. To maintain system resilience and modular compatibility you must however avoid certain habits; here's how. The four secret words are inheritance, overload, deprecation, and propertizing.
These are pretty standard concepts in the object oriented world, but using them correctly takes a bit of discipline. Part of the issue is that post-hoc seat of the pants changes are a poor excuse for thoughtful refactoring in the first place.
For example say you have a routine that estimates a car's mileage based upon a single measurement plus a date of measurement. This gets implemented as myCar.getCurrentMiles. Now your company wants to change the method to use two measurements and two measurement dates instead. How do you proceed?
Look at all the options and consider what they buy you, but also consider what they break.
The first and easiest option is the overload. You already have myCar.getCurrentMiles (measurement, date), now in the same class you add myCar.getCurrentMiles(measure1, date1, measure2, date2). Of course this new method starts out with the code that used to be in the old method (have the old method call the new method with null values for the second measure and date).
External calls using the old method will still work, and developers coding for this method will see both signatures in their intellisence pop up. This does have the drawback however of failing to provide much to the consumer in the way of choosing the newer signature of the method over the older. When to call it with one measurement, and when with two? More about the other alternatives for handling change in a later post.
