Is Object-Oriented ColdFusion a Myth?

ColdFusion has come through quite a metamorphosis over the last decade. Anyone who is familiar with ColdFusion 5, or even 4.5, can attest to that. In those days, there were no CFC's, and techniques for modularizing an application's code were limited to simply physically breaking the code into separate files and relying on the <cfinclude> tag and custom tags.

When ColdFusion MX was released, CFC's were introduced, opening the door for the basic object-oriented approaches. With each successive version of ColdFusion, new features have been introduced that bring it more in line with contemporary languages that are generally considered the pillars of OOP: Java and Microsoft's answer to Java, .NET. Even so, there are certain limitations to ColdFusion's OO abilities. The lack of true constructors is a glaring omission that I'd love to hear somebody at Adobe rationalize. ColdFusion does not support polymorphism per say, nor does it provide for multiple inheritance.

The community using ColdFusion has learned to slide around these restrictions though; everyone has seen an init function in a CFC, right? CFC's are quite popular, but I am constantly surprised how few people actually use a CFC as a true object – an encapsulation of data and methods. Very few people I have come in contact with can clearly explain how to store instance data safely in an object defined in a CFC. Many of the ones that are actually storing data in objects, rely on a framework to define, instantiate and initialize the objects and do so just because the frameworks help make their code pretty. The vast majority, however, seem to use CFC's only as containers for static methods. What could be a very powerful framework is being reduced to a utility for organizing methods, which is not all that far from the custom tags of ColdFusion 5.

There are probably many reasons for this lackadaisical use of the OOP paradigm that I've observed. Maybe I have seen a bad sample population; I know there are good ColdFusion programmers out there that understand and use OOP principles every day. But I'll go ahead and offer up some hypotheses:

• No ORM Needed – One of the fundamental strengths of ColdFusion has always been the ease with which it handles interaction with database systems. While other languages force the programmer to piece the SQL of the query together and then marshal the resulting data into an object or array of objects, ColdFusion takes in SQL and produces a query object (and yes, it is an object). Who needs to go to the work to implement an object-relational mapping when there is <cfquery>? I know ColdFusion 9 introduced ORM implemented in Hibernate, but I'm far from being onboard on that because I have yet to see an example of a ColdFusion application that would significantly benefit from Hibernate. The point is that ColdFusion itself is already really good, probably better than any other language out there, at handling data from a database system without user-defined objects, so the need to store data in CFC's has never been critical to an application's design.


• Individual Programming Experience – How many ColdFusion programmers came from an OO background? How many OO programmers go into ColdFusion? How many ColdFusion programmers have a computer science degree?
  


• Performance – Instantiating objects in ColdFusion is expensive. An average data-driven web site is going to have a whole lot of data objects being instantiated on the fly. If these data objects are just POJO-type objects, then one would have to justify the additional expense of instantiating all these objects that do nothing more than encapsulate data without offering any complex methods to operate on the data.
  


• Ease of Coding – Let's face it, in ColdFusion it's hard to instantiate an object and store data inside it. It's much easier to declare a struct and shove the data in there, not to mention the all-powerful <cfquery> tag.


• Informal Class Definitions – No formal definition of the data members of a CFC is ever made. Any method can add a private data member at any time (of course some other OO languages like Javascript allow this as well). Without a formal way to define the data members, it just isn't obvious that the data members should even be used. There is the <cfproperty> tag, but its use is limited to helping generate the WSDL when a CFC is exposed as a web service.


• History – Applications written for CF 5 or lower do not change to OOP without a lot of work. Similarly, programmers comfortable in procedural programming will tend to stick to that.

In the end, it might be the uniqueness of the ColdFusion language that is the underlying issue here. On one hand, it is one of the easiest languages to pick up and become fluent in, so understandably there are a lot of people using it that have had no formal OOP experience or schooling. On another, you have the extreme ease of database interaction with the <cfquery> tag and the loosely-typed variables that tend to make most of the formal programming paradigms out there seem like overkill. Even after considering all of that, can somebody tell me why it would be a bad idea to allow constructors to be defined in CFC's?