Procedural, OO and Me

Last week, I followed Ben Nadel as he worked his way through Hal Helms' week-long course on Real-World Training in OO (Object Oriented Programming). To be sure, I'm not the only person who followed his daily posts. That being said (or typed anyway), it blows my mind that Ben was able to muster up the energy to put his posts together while he was there. I guess one could chalk that up to his experience in blogging over the past few years, but still ... if you've ever attended a week-long intensive training class, no matter who you are, it's not easy to devote brain power and/or time to anything else but the task at hand, even if it is "on topic." Kudos Ben and thanks for sharing your experiences.

Unless you've been under a hard drive for the past year or so, you've been seeing and/or reading a ton of information, blog posts, articles, etc. about "Object Oriented Programming" and how it does/doesn't/can/cannot apply to ColdFusion programming. What all of this means for you as a ColdFusion developer most likely depends on a number of factors such as your level of programming experience, where and how you work (such as individual or part of a development team), the amount of time you have and/or make available to yourself for education and a number of other important factors. I can only speak for myself, but I wonder how this plays out in the larger ColdFusion community.

I don't know about you, but lately I've begun to feel like a second-class or second-rate ColdFusion developer because I'm still mostly a "Procedural programmer." Over the past year or so, I've been diligently working to move many of my repetitive tasks and methods into ColdFusion components (.CFC's). Using Application.cfc, I instantiate several of these .CFC's as objects in onApplicationStart(). Then, as I've needed a method here or there, I would invoke it as necessary. I can honestly say that I've been able to better "modularize" some of my more used "sub-applications" and reuse them in other projects. So I can truly see the upside of moving towards a more "OO" methodology. However, most of my applications are still primarily "procedurally" written. In fact, there may even be some procedural code within my .CFC's. Which reminds me of a recent podcast I listened to on CFConversations with Hal Helms as the guest.

After I listened to CFConversations Episode 13, an interview with Hal Helms, my brain just seemed to hum with activity regarding OO vs. Procedural and I found myself having to "re-listen" to many parts of the interview because I was so utterly lost in thought that my ears weren't taking in what I was hearing. (By the way, episode 13 is without a doubt my favorite CFConversations podcast and I highly recommend it!) One such particular point that provoked more thought than some of the others was where Hal mentioned something to the effect that because many developers come from a more database-centric background, developers tend to take the wrong approach toward object oriented programming. That wrong approach being the design of a database first, and then creating objects to represent that data, etc. An alternative approach could include using a more "Interface Driven Architecture" in which end-users drive the design of an interface (both front-end users and administration users) and then the developers could come in and create the objects needed to "bring the interface to life" so to speak.

Not to put words in anyone's mouth here, please know that I did not transcribe, word for word, what Hal said in his interview. These are merely my recollections, be they right or wrong, or be they intertwined with some of my other discussions/blog comments, etc. with others such as Clark Valberg and Peter Bell.

I'm finding myself buying into this line of thought of building a prototypical interface and then moving into a phase in which the interface would be "programmed." Now I'm struggling on how I can actually implement some of this into my daily routines. I'm always open to trying something new if it can benefit those who use ultimately end up using my creations.

At the end of the day, I feel as though I'm using a somewhat "blended" methodology with procedural, object-oriented and maybe even some aspect-oriented programming, yet weighted most heavily on the side of procedural. Is this such a bad thing though?

The primary argument laid out to entice developers to get onboard the OO train usually boils down to the ability to reuse some portion of code. Ask most any developer and I'm sure they would most likely agree that the ability to "reuse" code again and again is definitely useful. Who would want to type the same 500 or more lines of code for each project? In addition, how much of the code I write is actually "used?" If I could have a system or methodology that could reduce or eliminate "unused" code, then I'm all for it, so long as it doesn't force me into writing a matching amount of code just for "objectiveness."

For example, I ran across an application once that had a huge .CFC to handle calls to send a message via email. The .CFC was well over 1,000 lines of code and honestly could have simply been placed on the calling page/template and used a much simpler CFIF or CFSwitch along with CFMail. No initializing, no waiting, no muss, no fuss, just use the darn tag that was created to "objectify" the task of sending an email with ColdFusion. If you want to call that spaghetti code, then grab a fork. Please don't try to argue the "reusability" angle either, because CFMail is reusable all by itself. Seriously.

If anything, reading about the adventures of Ben Nadel and others have definitely inspired me to think ... to think about how their thoughts and opinions apply to me and my approach to development. So for now, I'm a developer who's happy learning what others are doing and how others are becoming more productive while hoping to pick up some good practices and maybe even become a better, more productive developer too.