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?

Pitfalls of Mylyn

If you don't know, Mylyn is a plugin for the Eclipse IDE that provides a task-oriented view of the IDE and helps automate a few tasks. It integrates with your project tracking tools, like Trac or Bugzilla, so you can get a list of the tasks (a generic word for tickets or bugs) that you need to work on right there in Eclipse. You activate one of the tasks, and Mylyn will automatically restore the IDE to the state it was at when you left that task by:

• Opening the files you were working on
• Changing the perspective, if necessary
• Limiting the navigator to show just the files falling inside the context of the task

As you work on the task, it keeps track of which files you access (even those you just view) and adds them automatically to the context of the task. When you're done with the task, you can attach the context as a .zip file to the ticket so another developer would be able to reference it later.

That's a short overview of some of the handy features of Mylyn that I use. As I've used it over the last few months, I have discovered two issues that I would like to detail.

First off, the task context will absorb any files that are touched by a SVN snychronize or SVN Update. When working in a team development environment, it's best to update your local working copies frequently to receive the latest code updates from the rest of the team to avoid any integration issues. Eclipse makes this easy by allowing you to schedule a refresh of the synchronize view, which will alert you to any incoming changes. However, any file identified to have incoming changes during a refresh of the scynchronize view will be added to the context of the active task. Additionally, if you perform a SVN update while a task is active, any files updated will also be added to the context of that task. I consider this to simply be a bug in Mylyn; it is needlessly adding files to the context of the task, to the point where the context becomes so bloated it is useless. There are really only two options for maintaining your task context:

• Deactivate the task before any SVN operations (which is hard to do if you are using the scheduled refresh of the synchronize view).
  
• Constanly remove extra files from the context.
  

The second issue is a by-product of what is really very useful feature that Mylyn provides: the commit comment template. This feature allows you to set up a default format to use for the comment when commiting code that can automatically insert properties of the active task. For example, you could set it up to default to "Refs [insert ticket number here]". This is especially handy when you are using the trac-post-commit-hook in your subversion repository to automatically update the ticket when you commit a revision for it, because you don't accidently mistype a commit comment and fail to trigger the hook.

The problem comes when a developer uses this template to completely formulate their commit message and fails to provide any additional information about the specifc changes they are committing. If a ticket ends up with several revisions, and you ever have to review those reivisions, you end up looking at a list of revisions with exactly the same comment. Not very helpful. This is purely a case of developers being too lazy to properly document their revisions (the infamous "lack of documentation" problem), but I would nevertheless categorize it as a potential pitfall of using Mylyn. It is not a reason to avoid using Mylyn in of itself, but it is something to be aware of and instruct your team to avoid.