Rob Wilkerson

Although I no longer do as much development using ColdFusion as I'd like, I still follow the community pretty closely and try to participate to whatever degree I'm able. Something I've noticed a lot of in recent months is the proliferation of blog posts dedicated to documenting the blogger's introduction to and initial steps with respect to object oriented programming (OOP).

While this is, in fact, one of the very reasons I still follow the ColdFusion community closely - the community as a whole is one of the few that is really wrestling with, and writing about, OOP concepts and their application within the web application context - I'm a little bothered about focus of so many of these posts.

I'm not an OOP guru and I'm not trying to play one on TV, but it concerns me that so many of these posts are focused on how to build an object oriented web application. The mechanics, I mean.  The posts seem to focus on which business objects to create and which helper objects are, or may be, needed. Alternatively, the focus is often placed on the discussion of a specific design pattern, implementation detail or which design pattern, if any, a particular implementation employs.

Given that kind of "documentation" it becomes far too easy for OOP beginners to simply read and execute these pseudo-instructions as some kind of checklist without understanding the core concepts of OOP. They're actually just substituting the judgment of others for their own and assuming that the solution being discussed is the best solution for their own application or worse, for any/every application.

At the risk of oversimplification, OOP is just a development principle that offers one method of decoupling the functional components of an application and, as a happy byproduct of a well-designed system, of very conveniently implementing the DRY principle.

Here's an example: There's been a lot of talk lately about the bean-DAO-gateway domain model. The bottom line, though, is that my application needs a data abstraction layer. That's the grounding principle at work here, I think. How exactly that principle is realized is almost inconsequential as long as the abstraction itself is fully realized and encapsulated.

I don't mean to imply that engineering an OO solution is easy. It's not. Nor am I saying that design patterns aren't important. They are. All I'm suggesting is that once the fundamentals of OOP are grasped and the process-centric thought process is stifled a solid design is born. And sometimes, within a well-designed system, even without knowing the name, a design pattern - or some variation thereof - is being implemented simply as a result of understanding the fundamental concepts.