An Architect's View

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

An Architect's View

Are Objects Bad? Revisited

December 20, 2010 ·

Michael Long posted a comment on my "Are Objects Bad?" post which I wasn't really sure how to answer effectively. Michael feels that if you're just working with functions, and grouping them so each file deals with specific concepts, you're starting down the road to OOP anyway so why not "bite the bullet" and use full-on OOP...

There are two things that don't sit well with me about Michael's comment. The first is that OOP is much more about conflating state and behavior to create self-contained 'smart' entities that more closely model the real world. Grouping related functions together is something folks have been doing in pre-OOP languages for decades. But it's interesting that Michael would make that observation and I can see how such a grouping could be seen as a first baby step toward OOP.

The second part of Michael's comment that made me itch a bit was "get the additional benefits it [OOP] provides". As I conceded in my original post, not everyone thinks OOP is all about benefits. Part of what made me pull back from 'pushing' OOP was that it has a number of downsides too. There's no 'right way' to design an OO application, which bothers a lot of people (true, there's no 'right way' to design a on-OO application either but many folks are either overwhelmed by the apparent choices or frustrated by the way that a poor OO design seems to punish you much more sometimes than a poor non-OO design). Another potential downside is the 'class explosion' problem and the ensuing navigation problems it can cause in understanding the code base. Other problems arise out of poor cohesion, excessive coupling and a whole slew of anti-patterns.

Many of these problems aren't entirely the sole purview of OOP but they can often be magnified in an OO design - and they are real problems for people new to OO as they drown in classes and patterns (and anti-patterns).

But there's a more insidious problem that OOP has slipped into our day-to-day lives that most of us really haven't noticed yet! Where we're beginning to see it in our web applications is issues of concurrency, where an object's state can be manipulated by more than one thread / request at the same time. Rather than try to explain it in more detail, I'll defer to Rich Hickey, creator of the Clojure language, who gave this excellent keynote talk at the JVM Languages Summit in 2009: Are We There Yet? - a talk about state, identity, value, time and other concepts.

Tags: clojure · programming

7 responses

  • 1 Michael Long // Dec 20, 2010 at 11:44 PM

    I replied again to your original article, but will add a few additional comments here as well.

    First, just let me say that I'm an object guy from way back. Smalltalk. Object Pascal on the Lisa. Taught C++. So I have a little background regarding the subject. And perhaps more than a little bias as well, to be honest about it. (grin)

    From my perspective, OOP is largely about managing complexity. Encapsulating it. Hiding implementation details. The metaphorical "black box."

    Second, my response to which you took exception [sic] had a few qualifications to it, so let me quote the relevant part of it again: "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."

    Or to put it another way, if you're a functional programmer, and if the project is large enough, then you're going to HAVE to come up with some way to manage project complexity.

    And that, in turn, usually comes in the form of creating a set of grouped, related functions, in a file (or a set of files), in which you're passing around common predefined structs.

    So. Defined data structures. Related functions. Related files. Hmmm. From my perspective, that's starting to sound suspiciously like what one would do if one were to approach the problem from an object-oriented perspective.

    In which case, if you bite the bullet and take that next step into OOP, you not only start managing that complexity, but you also start getting additional benefits, like encapsulation, like scoped and private variables, like inheritance, like security and threaded access, and so on. (Depending upon the language, of course.)

    And from there, you can go big time and jump into design patterns, frameworks, class libraries, ORMs, and business objects. Those tools, in turn, start doing much, much more of the heavy lifting. That lets you, the developer, stop worrying about whether or not you're correctly passing NULL on a INSERT, and instead focus on the big picture.

    And yes, there are probably some projects or systems where OOP is overkill. Heck, I still tend to write report-style admin pages the same way everyone else has done since CF 3.1. A form submitted to a query with looped output.

    But it's amazing how often even a small project starts growing in complexity. And OOP gives you the tools to deal with it.

    It was once said that with a lever large enough, one could move the world.

    OOP is that lever.
  • 2 Ben Nadel // Dec 21, 2010 at 7:36 AM

    I am about to start day 3 of Erlang which, I believe, will be talking about concurrency again. I am hoping that this time it will start to make sense to me. Of course, understanding concurrency in the context of a functional language might not lend all that much valuable insight into concurrency in the context of an Object-Oriented language like ColdFusion.
  • 3 Dave Burns // Dec 21, 2010 at 8:40 AM

    Sean - You might enjoy this tangentially related post which tells an amusing tale about frameworks and how OO-think can take them overboard. There is a useful follow-up halfway down from the original author about frameworks vs. libraries.

    http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
  • 4 Jake Munson // Dec 21, 2010 at 11:33 AM

    I really appreciate this post. This describes many of my OO experiences perfectly: "...real problems for people new to OO as they drown in classes and patterns (and anti-patterns)"

    I am not opposed to OO, but it seems to me that many people in OO take OO too far. Not only is the code hard to follow, but I wonder about performance.

    For example, I read a comment on an OO/CF mailing list once like this: "You should create an ORM object for every record in your database." What?! Our database has millions of records across hundreds of tables. Creating that many objects in memory seems like suicide to me.

    My final thought is that it seems to me, Sean, that you are allowing for a simplified approach to OO. In fact, if I understand correctly, your fw1 framework exemplifies this. If I am not misreading you, then I say, "Bravo!" :)
  • 5 Sean Corfield // Dec 21, 2010 at 2:59 PM

    @Michael, I find it interesting to be on the "other side" of an OOP discussion :) You are clearly more of an OO proponent that I am since I find myself wanting to argue against your points!

    @Ben, yes, functional languages tackle concurrency (mostly) by simply avoiding all the problems associated with shared, mutable state - problems that are fundamentally inherent to an OO approach.

    @Dave, yes, the "enterprise hammer" piece is very entertaining (both BenjiSmith's original and the subsequent four part dissection of Java frameworks on the Relevance blog from November 2005 if you follow the links :)

    @Jake, I've always been in favor of a pragmatic approach to OOP but unfortunately my enthusiasm seems to have led some CFers into a minefield because they wanted the "perfect OO design" (which doesn't exist). Nowadays I'm trying to be much more explicit about my pragmatism (and my favorite phrase "It depends!") and I'm trying to make sure folks understand that I don't only do OOP - in the hope that they also explore other approaches.

    When I saw what some people were trying to do in CFML with OOP, I tried to encourage folks to look beyond Java (which forces everything to be a class / object) and draw inspiration from other, more pragmatic, more dynamic languages. Now that functional programming is finally getting some mainstream attention, I feel I can reasonably point CFers at that too, as a way to learn new approaches and add new tools to their belt!
  • 6 Jaime Metcher // Dec 22, 2010 at 7:20 PM

    @Jake,
    OOP has a very long reach. Your database server is almost certainly written in C++. Your phone is probably running Java or Objective-C. In the narrow context of ColdFusion performance is certainly an issue, but more widely it's orthogonal to the merits of OOP.
  • 7 belun // Dec 28, 2010 at 12:37 AM

    shouldn't this talk be about encapsulation, the base of oop ? i mean, people keep talking about "oop" as in "objects" (objects programming), but the basis of it is encapsulation. that's the theory, how it has started.

    i think the discussion (thus analysing, comparing, bashing :) and others) should be around encapsulation vs, i don't know, code is data (or whatever is the base of functional programming)

    talking oop is confusing as it's not only about objects. oop is the name given (just a name) to something... and is quite confusing as the correspondence to real life isn't that good; "oop" is a metaphor at this point (looks like objects, but it's not quite that)