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!
7 responses so far ↓
1 Michael Long // Dec 9, 2010 at 1:52 AM
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
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
4 Jaime Metcher // Dec 19, 2010 at 8:35 PM
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
@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
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.
Leave a Comment