OO Design Principal: Separate Changing Functionality
Identify the aspects of your application that vary and separate them from what stays the same.
The idea here is to encapsulate functionality that will change, so that they can be easily altered or extended without affecting other parts of the system. The benefits are pretty obvious, there will be fewer unintended consequences from code changes and add increased flexibility in your code base.
This principal is the basis of most design pattern and object oriented design principal.
Antidote: I recently worked on fixing an issue with a java based facebook application where the profile writes and the mini-feed update functionality was broken. In looking at the code it became clear that the original author of the application embedded this functionality in each method that performed the writes. Facebook is notorious for changing their API often which can lead to broken functionality in application written for their platform. It was difficult to find all of the code sections that did a facebook write and a change in the facebook API meant the each method that implemented the write needed to be changed. If the original author had been aware of this design principal and the fact that the facebook API would be a consistent point of change in the application they would have moved the write functionality to its own utility class. This way any facebook API changes would need to be changed once and all methods the relyed on the utility class would have the benifit of the updated code.
