Unless you’ve been coding under a rock since ColdFusion 4.5, you’ve likely noticed the massive momentum behind object-oriented design and development in the ColdFusion sphere over the last 2 to 3 years. I love the idea of designing apps using object-oriented techniques–so much so that I’m presenting a session titled “OOP: What is it and why do I care?” at NCDevCon next month. After a while of developing OO-style applications you can get really spoiled to that way of writing and organizing code.
As a consultant, I get the opportunity to work for a wide array of companies and an even wider array of projects–not all of which are designed and built using the latest and greatest OO principles. Sometimes you can fall into the trap of thinking how you’d do a certain thing in an object-oriented way when the application you’re working on is written in a (good or bad) procedural manner. As tempting as it might be to scrap the client’s procedural code and write a shiny new OO block of code, you have to step back and remember what the client is paying you to do and decide if that’s the best use of the client’s money.
Unless the client is specifically paying you to refactor an older application, sometimes it simply doesn’t make sense to change the way the client’s application works so drastically. Sometimes you just have to “forget” all the OO goodness that you’ve learned to love over the last couple of years and go back to the “old” way of doing things in order to best service your client. It may not be fun, exciting or cutting edge work, but there are still a great number of procedural applications out there that we might be called upon to work on.
Disclaimer: This post was written as a “note to self”, not as an indictment of anyone that I have worked with.