Why Interfaces In ColdFusion Are Irrelevant
A post from Sean on Static vs. Dynamic languages reminded me that I needed to get around to finishing up a piece I started long ago about why I think Interfaces in ColdFusion are completely irrelevant. In particular, this quote is what reminded me about it:
I've built large systems in dynamic lanaguages. I've built large systems in static languages too. Neither is necessarily better or worse than the other in terms of maintainability - if you know what you are doing.
To me, a decent but not perfect general comparison of dynamic languages to static languages could be summed-up as a pair of safety scissors vs. a razor blade. Static languages are the safety scissors-- they help protect you from cutting yourself and will probably last longer, but it might take a long time to cut something. Dynamic languages are a razor blade-- they are very sharp and nimble and cut through most things very quickly, but they are easy to cut yourself with if you're not careful and may have a shorter shelf-life depending on how they are used. Granted I don't think this quite applies to any language in which you need to do memory management (C, C++, etc).
Since the introduction of ColdFusion MX, we've been able to use ColdFusion Components-- ColdFusion's take on Object Oriented Programming. CFMX 6.0 was certainly an "interesting" time for CFC's, but luckily a lot of changes were made and CFC's have basically stayed the same since CFMX 6.1. Since that time a lot of ColdFusion developers (including myself) have jumped on the OOP bandwagon (with great community evangelists and teachers like Sean Corfield and Hal Helms, how could you not?) and as we've progressed along we've wanted more and more rigid OOP practices available to us in CFC's. There was a time when I would have liked to have interfaces and would have debated the topic to death in favor of them, though quickly my desires for them dissipated and now I don't really see the point of having them in ColdFusion.
In Java, one of the advantages to using an interface is that it does compile time checking to make sure that classes implementing interfaces follow the contract dictated by the interface. Since ColdFusion is a dynamic language, there really isn't a good way to do compile time checking of interfaces, so it would be a pointless endeavor.
When I find a need for an interface in ColdFusion, I essentially create my own pseudo interfaces / abstract "classes" which at least provide run-time checking in case an inheriting object's method is called. It's not a very good solution, but it does at least offer some sort of contract that an inheriting object can be tied to, mostly for documentation purposes. I've seen several other people do it as well, but it looks something like this:
These are just poor pseudo-code examples, but you'll get the idea.
Overall, I think the bad reputation that dynamic languages get are because they are so easy to program in so most anyone can do it, while static languages like Java force even bad coders into at least some semblance of decent coding practices. I think it really all comes down to experience, discipline, and knowledge.
In summary, due to the nature of dynamic languages, the implementation of interfaces in ColdFusion would not prevent someone from breaking the contract of an interface before runtime, so I think there are bigger problems to solve in the next version of ColdFusion, currently code named Scorpio.