As a former Visual Basic/ASP classic developer, I live with a lot of guilt. I’m haunted by memories of sloppy designs and even sloppier implementations. The only mitigating factor is that it’s unlikely I will ever see any of that code again. Fortunately, that geek-guilt provides me plenty of motivation as a C# developer to get better at what I do.
The single greatest challenge I faced in the transition to .NET was learning Object Oriented Programming techniques. VB had rudimentary support for some OO features but nothing I ever worked on utilized that aspect of the language. For me, .NET was starting from scratch.
I have to admit that at first glance OOP appeared to be an exercise in academic counterproductivity on a grand scale. Where I could concisely write some functionality using a few methods, OOP would demand several classes, interfaces, and supporting infrastructure. All this overhead, it seemed, just reduces performance and makes the flow of control harder to trace. With tight deadlines and an established 2:1 ratio or greater of debugging time to coding time, who in his right mind would spend extra time adding code bloat that makes the application less performant? This went against everything I knew as a developer.
Fast forward a few years, and now I’m a faithful OO convert. What I didn’t realize back then was that OOP obliterates my 2:1 rule altogether. By working with well-factored systems I came to realize that debugging time is not a static, unavoidable side effect of coding. Maintaining clear separation of responsibilities among classes allows you to reuse code that you already know works well. Automated unit testing ensures that any breaking changes you make to existing code are identified quickly before they become obscured under layers of new development.
I wish Jeremy Miller had been mailing out post-it notes (or whatever it was people used to communicate before blogs) when I was going through my OO transition. In this post on orthogonal code, Jeremy leverages a real-life experience he had to demonstrate the power and value of refactoring to a better design. If you’re new to OO and still struggling to put the pieces together (and keep them there), bookmark that post and reread it once a week.