CFCs aren't Objects; they're Abstract Data Types (But what's the difference anyway?)

Vince Bonfanti's wrote a post about CF as Java Lite, and whether CFCs were a mistake in the first place. Sean Corfield also put up a response to Vince. Read both those posts.

Since my commet to Vince's post was becoming a bit long, I decided to turn it into my own entry.

To sum it up, CFCs give ColdFusion the ability to encapsulate both functionality and data.

I believe the ability to encapsulate both data and functionality is an important feature of the language regardless of whether you are using OOP concepts (Objects) or procedural programming concepts (Abstract Data Types) with ColdFusion.

For long time we, as CF Programmers, have been able to encapsulate functionality. We have custom tags, User Defined Functions, and (to a lesser extent) includes. But there was never a way to encapsulate data. Every call to a Custom Tag or UDF is treated as an independent call. It doesn't know that you already called it, and the internal state is always the same.

It always bugged me that this ability wasn't in the language. The lack of this was a common complaint I made in my CF5 days. I even created a presentation that proposed a way to achieve that sort of functionality in CF5. The method I used was all smoke and mirrors, using UDFs and includes, to emulate encapsulation (without actually being encapsulated). CFCs are a much better implementation of this concept.

(Note: The initial presentation was pre-CFMX, but the current one does include CFCs)

I got a lot of "why bother" responses to the presentation and people had a hard time understanding where I was coming from. Programmers got it, but many CF Developers didn't come from a programmer-background. I received a lot of glazed-over looks. People have a hard time distinguishing the differences between Object Oriented design and a Procedural Design. I believe I had an equally hard time explaining the differences (but I'm smarter now, I swear it).

The best (and simplest) way I've heard the differences between OO and Procedural programming described is by Peter Bell in the comments over at this post. To bastardize his quote:

In Procedural Programming, you request data and perform actions on it. In OO programming you're sending an instruction about what must be done to the data. Since most programming languages are hybrid languages, offering both OO and procedural features the line between the two has become very vague.

I once had a friend claim that he has "seen -many- programmers use Java procedurally". It does confirm what I have heard others say. I have not worked with enough Java (or C++) programmers to make the claim myself. Since Java is considered the most prevelant OO language of today, it is interesting to think about its use with procedural design.

If your objects contain nothing but get methods that "return variables.foo" and set methods that "cfset variables.foo = arguments.foo" then perhaps you aren't nearly as Object Oriented as you thought.

Tell me I'm wrong.