An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Are Objects Bad?

December 8, 2010 ·

I've had a number of people criticize me for 'pushing' OOP as the One True Way(tm). Some people have even raised the somewhat infamous "tablizer" OOP-is-bad page (sorry, I'm not going to link to it!). Whilst I am a big fan of OO as a good way to model the real world in software, I try to be pragmatic about what works and I don't believe in One True Way(tm). Heck, I've become famous (notorious?) for saying "It depends!" when asked about the 'right' way to do something!

My first programming model was procedural (I feel I should I say "of course" since that was so long ago). I did C and assembler. At university, I learned a lot of languages (mostly procedural) and my final year project was to write an APL interpreter and then I did three years (PhD) research into functional language design and implementation. It was a time when interest in functional programming was high - with SASL and Miranda and so on. Shortly after that time, a smart group of people in Oxford worked on integrating OO and Functional styles. I moved on to writing compilers and then worked with C++ and eventually switched to Java in 1997. By that time, I'd absorbed the OO mindset and Java's "Object-Only" approach didn't seem too weird.

For a long time, I sort of forgot my procedural and functional roots. In 2001, I found myself exposed to CFML and tackled it much the same way I'd been tackling Java for a while. Over time, I started to pull back my old school programming mindset and adopted a more dynamic approach to CF development and - despite an early push for cfinterface - I began to 'preach' a more relaxed, less Java-like approach to CFML.

Recently, folks have seen me talking more about functional programming, with coverage of Scala and Clojure. For me, this represents the closing of a circle. We've gone so far that we're seeing a merging of styles and a new middle ground appearing.

With all that in mind, I just stumbled across a 2006 blog post raging against Java's "Object-Only" approach and it really resonated with me: Steve Yegge's "Execution in the Kingdom of Nouns". Enjoy!

Tags: architecture · coldfusion · programming

7 responses

  • 1 Michael Long // Dec 9, 2010 at 1:52 AM

    If the project is large enough, you're going to start grouping common functions together anyway. Say, one file or set of files that contain functions that manage customer interactions, another that manages orders, and so on.

    In other words, you're creating a set of pseudo objects with related functions, without actually using OOP.

    In that case, you might as well bite the bullet and use OOP and get the additional benefits it provides.
  • 2 Raymond Camden // Dec 9, 2010 at 4:21 AM

    It's interesting - yesterday in the panel discussion someone raised the question about a style guide. I mentioned how you published your set of CFML styles/best practices/etc and that folks began to take that as the "official" Macromedia 'rules' for how CF should be built. Sometimes - no matter how much we try - folks just hear what they want to do.

    I can say that for myself - you helped me learn that blindly copying other people's code w/o thinking about it is a mistake. So thank you. :)
  • 3 Eapen // Dec 9, 2010 at 8:08 AM

    There are 10 kinds of people, those who understand OOP and those who don't. (borrowed from the binary joke)
  • 4 Jaime Metcher // Dec 19, 2010 at 8:35 PM

    Actually, your various postings over the years taken as a body are a nice example of a professional practitioner developing and evolving a view. It takes guts to do that out loud, in public - commitment and flexibility look like dogmatism and inconsistency to those who just want to be told what to do.

    Yegge's article is hilarious. I reckon all OOP old hands will have got to a point with Java where we wonder why our elegant paradigm produces such butt-ugly code, and Yegge certainly exposes Java's pimply bottom for all the world to see.
  • 5 Sean Corfield // Dec 20, 2010 at 8:34 PM

    @Jaime, thank you. I like the principle of "strong opinions, weakly held" :)

    @Michael, I've been trying to decide how to respond to your comment. A file with related functions in it is very, very far from OOP: there's no data / state involved and that's one of the key features in an "object" - it conflates state and behavior.

    I'd highly recommend watching Rich Hickey's "Are We There Yet?" talk as a good exploration of OOP and what we've gotten used to (and what we've inadvertently given up). I'll dig up the link and post it as part of a new blog entry.
  • 6 Michael Long long // Dec 20, 2010 at 9:10 PM

    No need for that. Been an object guy since Smalltalk.

    As for "object state", that was usually done in the functional world by passing structs, or in C, pointers to malloc'd structs. The original Mac OS and Windows APIs worked that way. Tons of related functions all operating on struct pointers (or handles).

    I've actually been doing objects in ColdFusion sine 3.1. I created a struct system with a single method dispatch function that allowed object-oriented function calls. It had an ORM layer on top of the base object management code, and even supported inheritance.

    Was about halfway to releasing it into thenCF community at one point... Right when MX and CFC's appeared. Oh, well.
  • 7 Laurent Petit // Dec 30, 2010 at 7:31 AM


    Hey, really, it's not C-style "datastructures+first class functions" versus Smalltalk-style "class based object orientation".

    It's more Smalltalk-style versus "CommonLisp Object System-style" object orientation.

    With the first, you only have polymorphism based on the type of the object on which you invoke a method.

    With common lisp generic functions you have polymorphism based on the types of all the arguments of the generic function you invoke (thus solving the double-dispatch and n-dispatch problem), and also providing an interesting solution to the Expression problem, by the way.
    With Clojure protocols + types, you have polymorphism based on the type of the first argument (somehow like in smalltalk, plus protocols help grouping relating functions together in interfaces - a java goodness)
    With Clojure multimethods you have an even more generic system than common lisp generic functions, since clojure multimethods allow you to have polymorphism based on a dispatch key derivable from any aspect of the incoming arguments: their type if they have one, or anything you can derive from them by calling functions on them.
    These surely are very powerful tools for managing complexity in a project !

    All the above is gained by not conflating data and behaviour.

    Not conflating identity and state is another interesting story, already spoken about by Sean.