About a week ago, Marc Funaro wrote an interesting blog post about CFML and OO. The prevailing opinion (via Twitter, blogs, etc) is that Marc is incorrect/inaccurate/inexperienced/whatever, and I disagree completely. He hit the nail on the head.
HTTP is a stateless, request-response environment. Nearly all web applications interface with a SQL database, which is also a predominantly stateless request-response environment. Those are orthogonal to the core OO principle of interacting stateful objects. It's far closer to the FP (functional programming) paradigm, but particularly on the SQL side, still doesn't match completely.
To use OO in a SQL-backed web app, you hide the mismatches with ORM, an object-based Front Controller implementation, and session facades. As Marc points out, Java works pretty well in this paradigm for two main reasons: Java is crazy fast, and Java developers have invested ridiculous amounts of effort in tooling to support this model. CF has neither of these advantages. I'm not belittling the effort poured into various frameworks (Fusebox, Model-Glue, ColdSpring, Transfer, etc.), just that they are significantly behind what is available to Java developers.
Unlike Marc, I happen to think that a Front Controller framework is essential, but I don't use a OO one for exactly the reasons he outlines. I build FB3lite for just this purpose: 70 lines of straightforward procedural code that help me enormously with certain common tasks. I often masquerade my apps as standalone pages with mod_rewrite (converting /viewUser.html into /index.cfm?do=viewUser), but that's a cheat.
I also use CFCs and ColdSpring for my business tier, but no object (domain) model for me. The CFCs are really just glorified function libraries that I can use ColdSpring's AOP engine to wrap transactions around without having to manage them explicitly in my code. In order to get the AOP I have to use CFCs, and I like the namespacing they provide (so I can have a 'doThing' method in multiple namespaces without conflict), but there is no real OO-ness there.
I know what you're saying.
Yes, I often preach the benefits of OO and encourage people to learn about it and use it. But using a howitzer to hunt mice in your garage is not a clever idea. If I'm writing Java (or Groovy), I'm going to use OO structures, but that's because of the programming environment. I am a pragmatic person. I like to learn about a wide array of tools and then use as few of them as possible, knowing that there are other options available if I need them.
Yes, built CFGroovy with Hibernate support so I could use ORM in my CFML apps via Groovy objects. It provides the best of both worlds, the speed and tooling of Java in a CFML environment. That approach works quite well, but if I don't need the complexity, I'm not going to do it.
Well said sir.
The "framework" I have been using for years is much like FBlite. It offers encapsulation, clean separation of logic, data model and presentation. It is decidedly not OO. It is just a way to organize with out a lot of overhead and complexity.