OOP and the Evolution of ColdFusion

I hear alot of arguments (particularly of late on the CFAUSSIE mailing list) about ColdFusion and Object Oriented Programming.

It seems that almost even the most tangential conversation that could possibly relate to OOP, degenerates into pointless bickering about how OOP is good, bad or ugly when combined with CF.  It's verging on rediculous.

The facts remain as such – Object Oriented programming has been THE software development paradigm for more years than I have been alive.  There is a REASON why we don't code in procedural code anymore, and a REASON why Object Oriented programming has come into almost every aspect of software development.

Looking solely at Macromedia related products.  CF was procedural, and then came along CFC's.  Flash was… well, Flash… and now you can define classes in Actionscript. Blackstone will further enhance CFC's with Event gateways and the like.

The truth of matter is – the Future for Coldfusion IS OO. You can like it, you can hate it, but quite frankly, if you develop with CF, Object Oriented programming is here to stay, and there is nothing you or anyone else can do about it.  All it's every going to do is infiltrate more and more of the CF development community, as the years go by, and the support for it in future ColdFusion versions grows.

Yet again, I implore you – if you want to develop your software development abilities with ColdFusion go and drop into a Java course.  Not only will it give you the theory you need to stay with the time in ColdFusion, but it also provides you with the ability to combine CF with it's sister language, and give you capabilities with this language you never had before.

Can that really be a bad thing?

Leave a Comment


  • Charlie | July 30, 2004

    Great advice, but as a CF-er who’s trying to get into this, understand that it’s a daunting process. Is it best to just jump into attempting object based CF, or do we need to stop everything and start going through a 400-page Java book?

    Having tried a bit of the latter, it can be frustrating to output "Hello World" in a console and then wonder how and when all the theory ties back to real development.

    It will take some patience and a lot of free time, I guess.

    I hope more resources become available for helping pure CFers to begin taking advantage of what is out there.

  • Brian Kotek | July 30, 2004

    I’d recommend a conceptual OO book first, like "OO: A Managers Guide", which is almost all theory. It’s very easy to read and will get you into the right mindset. Then read "Design Patterns Explained", another easy read and one that will make you start thinking about how to structure an OO system. Finally, go nuts on a Java book. 🙂

  • barry.b | July 31, 2004

    1) no one is holding a gun to CF programmers heads forcing them to use OO principals in their code – it’s just the smart ones that do so
    2) not all jobs are perfect for coding this way – but most will benefit
    3) just as you could write brilliant procedural code, you can also write crap OO type code.
    4) yeah, yeah. CF isn’t a full-on OOP language – but it will do 80% and is still a great RAD tool to work with. Only on rare occasions will you want the missing 20%.
    5) OO design really isn’t hard – just sometimes it’s a bit "deep". It’s like taking the idea of a function and multiplying it by a factor of 100 or so. black-box everything and create an API to access it. Abstraction, encapsulation, loose-coupling. tight cohesion (ie: inside CFC’s) – these aren’t just buzz words. They’re smart ideas that for the last decade(s) have helped to work towards a better solution to increasingly complex problems. Not by working harder (procedural programming) but by working smarter (OOP)

    my 2c

  • Johnn Boursiquot | July 31, 2004

    Why is it I wonder, that some CF programmers still so vehemently fight OOP? Is it that it is such a new concept that we’re fighting the idea of doing something a way we’re not used to? Can any procedural programmer actually look at OOP, understand why it exists and deny that it is a better approach to developing software?

    Hmmm…..Are we so comfortable doing things the way of CF 4 and 5 that we refuse to embrace the next generation?

    Well, to those who are resisting: good luck to you. My first has made it a rule not to hire any programmer without understanding of basic OO concepts. Everything CF we do resides inside CFCs. We emply MVC pattern development and we’ve seen so much better results out of all these things.

    Procedural programming was a good thing, but like all things, its time has come and is about to be gone.

    Step up CFers, or be left behind. Simple as that.

  • Mark | July 31, 2004

    In all honesty, I was expecting alot of people to jump at me for making those comments, rather than the support I’ve been getting from you guys.

    Charlie – I understand your connundrem. Depending on how you learn, I honestly think doing some sort of course in Java (or another language) that requires you to do project work of some kind, is the best way of developing your skills in that field. I know I have a hard time doing project work when it’s ‘just me’. But as stated in a previous post, I don’t suggest trying to learn OO through CF, it’s just too hard.

    That being said – Brian has a couple of good books there, so that could very well be a good avenue to go down (I fixed up your double comment Brian).

    Barry, Johnn, I agree with both of you whole heartedly. Thanks for your comments! :o)

  • Roger Benningfield | July 31, 2004

    My apps are procedural. I understand them. They work. I am not going to stop understanding them, nor will they stop working, simply because OOP is now in vogue among vagabond CFers looking to add a buzzword to a resume.

    I’m happy to use CFCs and the added options they provide. I think it’s great that MM invested in their addtion to CFML. And if people can use them for OOP while I use them as convenient, memory-resident function libraries, hey, that’s fantastic.

    But many of us (and I daresay that’s a very large "many") will continue along as we have, perhaps adopting bits and pieces of OOPish behavior into what we’re already doing without changing much. And that will be a good thing.

  • Mark | August 1, 2004

    Just to make it perfectly clear:

    Nowhere have I said that procedural code will not work, or that developers would not understand it.

    (Although I am contemplating wearing a handkerchief to work on Monday, just so I can fully be described as a ‘vagabond’ CF developer ;o) )

    I am simply making the point that CF’s way is going to eventually be the OO way.

    If you wish to provide examples in industry where procedural code has dominated, I would love to hear it, as I’m always up for interesting debate.

  • Arindam Biswas | August 2, 2004

    Part of this discussion stems from the fact that the early coldfusion developer loved the product (and still do) because cf made complex things look simple, <cfmail> and <cfquery> probably the biggest examples of all. And procedural code is, arguably, simpler to understand than OOP. I am a toddler in OOP terms (4 years) and sometimes designing classes (components) makes me reach out for asprin. But listeners, beans in Mach-ii gladden my heart in the long run. Trust me, its a pain initially but the pleasure returns after a while. Now where have I heard that before? *runs 4 cover*

  • Tom Minderson | October 16, 2005

    I beleive that OOP is "in" because it works well with systems software and low-level tool building. However, OOP seems to have a problem in the business domain. When people realize this, they will stop forcing OO down business developers’ throats. What is good for the goose may not be good for the gander.

  • monhun | July 3, 2006

    Bla Bla did you do something on OOP before saying that, probably no if you can say like BUSINESS DEVELOPERS LIKE PROCEDURES, they are stupid – sorry OOP is future of CF

  • Tom Minderson | July 19, 2006

    Reply: I have asked for examples with semi-realistic code of OOP being better in the biz domain, but have never seen a convincing example. If OOP fits the way you personally think better, that is one thing. But to say it is objectively better, you need to present something dissectable or measurable. This is the age of science, not the age of anecdotes and pushy kings. I have seen relatively convincing examples for systems software, so I CAN see OO helping other domains; thus, I am not blind to its potential "goodness". But the change patterns of sys soft don’t map well to change patterns I see in custom biz-ware. There is a reason most book examples use mostly system software examples: that is all they can safely rely on.