Monday, August 20, 2007
Putting Object Oriented CF in Perspective
After reading this post from Ben Nadel last week, I got to thinking about an OO reality check. I'm doing an intro to OO in ColdFusion tomorrow for our staff, and one of the things I plan to emphasize is that these techniques are another tool for their toolbox. While there are times that OO will be the best tool for their project, there may be times where it makes little sense. I'm not going to pull out a nail gun, when a hammer is all I need. On the other hand, when I do really need the nail gun, sticking with a hammer is kinda silly. (not to mention slow)
The thing about OO is that it takes time to learn (I'm two years into the process, and still have a long way to go.) That doesn't, however, mean that I haven't been taking advantage of OO during that time. I see this as a Yahoo's problems are not your problems type situation.
But also realize that Yahoo's problems aren't necessarily your problems. There is no such thing as one-size-fits-all guidance. Strive to understand the advice first, then implement the advice that makes sense for your specific situation.
I code things the best way that I currently know, until I get into a situation where I say, "There's got to be a better way!", then I go out and figure out what that better way is. This not only grows my skills when I need it, but also means my applications use these techniques when they are required. I've read about this idea of development several times when dealing with design patterns. The idea is that design patterns were meant to be used to solve problems when they are needed. Using the most design patterns doesn't mean you win. I believe the same holds true for OO concepts. I've been recently dealing with an application written by a couple of developers who are no longer working with us. They were so focused on OO purity that they ignored many of CF's native features. In the right situation each of these decisions might make sense, but in this case, they combined for an application that is harder to maintain than it would've been if they had been focused on writing simple and maintainable code.
Perhaps Ben's difficulty in understanding a specific OO concept is that he's not yet really needed it. I'm not in any way suggesting that we don't spend time on learning things that we don't yet need to know. I've bookmarked some of the links from the comments to that post, and will read them as time permits; however, most of the code that I'm writing these days will continue to use Transfer, Reactor, or simple gateways and DAOs, which has been meeting my needs quite nicely. When I need something more, it's nice to know it's there, though. And please, keep up with the great posts and discussions on advanced topics.
The bottom line here is that effective development means using the right tool at the right time. There have been a number of times where I've started sections of code with comments explaining that if this section is expanded, it should be refactored to be more OO first (usually with a detailed explanation of what to do), but for the sake of simplicity and expediency, I’ve written it in a more procedural fashion. Occasionally, I go back and refactor those bits of code as the situation warrants. Other times, I just let them run as they are. It may not be the most textbook code, but I find it effective.
Labels: ColdFusion, Design Patterns, Object Oriented Programming
posted by Luis
