OO Programming – its not just to make maintenance easier
Most of the time, when I do OO programming I have maintenance, and quality in mind. I refactor fairly aggressively to do this. But today, it was brought home to me that speed of developing new functionality can be serverly hampered by non-OO code. It went something like this:
We have this ASP.NET project that has been on very tight schedule, and thus had a large amount of copy-and-paste style programming, with a smattering of global functions.
My problem when working with this code was that I was lost. I understand ASP.NET, and web programming, but I guess I have become used to encapsulated objects that hide implementation details. So when I needed to display a user’s thumbnail photo (something done at least 7 other places), I kindof expected that I would not have to know about exactly where or how it was stored – I should just be able to ask some object for the URL, and it should be there.
Ha. I wish. An hour of code-reading later, I finally figured out the 3 parameters I would need to be able to do this. I now understand exactly how the photo-subsystem works…but I don’t really care! I just wanted to be able to display one little thumbnail.
I refactored the code to extract the photo-path logic into a single class, and discovered 2 bugs in the process, and probably fixed a few more I did not even notice.
So, if I every had any doubt that following OO principles was not “the best way to do things”, that has been quite healthily dispelled. I will continue doing things the way that I do, and in addition I will be a little more aggressive in encouraging similar practices in others.
