Is ‎Object Oriented the best?

I’ve been hearing sincere complaints lately about object oriented programming, about the Craftsmanship Movement, about Agile development practices. I hear from folks who are excited about functional (denotative) programming, who write concise little functions with one character names. (Some have objections to TDD, or think pairing is costly, but those are on the edge of what I’m talking about). And I’ve been wanting to really listen.

And of course, I hear a lot from folks who love TDD, love Object Oriented structure, love pair programming and long method names. And those are the folks I hang with, for the most part. So I’m wanting to listen to all of it, and see what I hear.

Though I sometimes hear that Object Oriented is “just better” or that TDD is “always appropriate” — what I call Argument From Fist-on-Table — that idea doesn’t help me much. In listening, I’m looking for better at what? and appropriate to what end?

So for many months I’ve been wondering why I’ve been pretty content to love OO programming (though I can see the mathy beauty of FP*) and why I love the things that get called “clean code” (without loving the setting of it as a categorical imperative). Talking to @kaleidic this morning in the wee hours, I realized what it is that I love about them.

I love the whole shebang — “craftsmanship”, TDD, the Four Rules of Simple Design, long names, etc. — because I love collaboration. Not just because it’s juicy and fun, but because it supports the emergence of good systems, and things like flexibility, responsiveness, changability. I love having a shared code base, and object oriented “craftsmanship” is a strategy for getting that.

I also love evolution, and folks following the sparkly stuff, so when I see smart friends like @kaleidic and @conal and @tunixman railing against object oriented programming, for example, I’m excited about what they’ll come up with. But I realize that whatever techniques emerge, they won’t just have to be about faster or even more accurate code to make me love them. They’ll have to fit into the collaborative social structure that makes Agile so beautifully effective.

* Really itching to work on Conway’s Game of Life without state changes, in fact.

A question anyway

So I answered this question for myself, but I am still curious. What is important to you about your preferred style of coding? If you’re an Agile developer, why do you love long names and TDD and objects? If you’re a Functional / Denotative Programmer, what do you love most about your code? Can it be made collaborative in the way I’ve described?

13 thoughts on “Is ‎Object Oriented the best?

  1. Sean McMillan

    Agile people love OO because it’s part of the same culture; There’s a chain of things that looks something like this:

    Object Orientation -> Design Patterns -> SOLID Principles -> Refactoring -> TDD -> XP -> Agile

    Agile arose out of a set of explorations into what the best way to build object oriented software. Asking why agile people like OO is like asking why Americans like speaking English.

    Now, there’s no need for agile and OO to be tied at the hip, and you can certainly have an agile project using functional tools. Of course, if you do FP, you’re using a different set of conceptual tools too. SOLID and Design Patters are either inapplicable, or highly mutated. Immutable objects and function composition become the tools of choice, rather than types and instances. I don’t know FP well enough to say more. Hopefully, someone who does will speak to it.

    I’m not a fan of long names; If I have along name, it’s because I didn’t have the time to make it shorter. ;-) The key is to have intention revealing names, so people reading calls to that code can tell what the heck it is. Objects are a great way to compartmentalize complexity; If I don’t need to know how it’s done, I can just trust the object to be doing the right thing. That lets me keep fewer moving parts in my head while I’m working on a problem. TDD lets me build up my objects one part at a time, and provides me with a test suite to make sure I haven’t broken their expected functionality as they change, which lets me refactor.

    Communication, lower mental weight, and refactoring.

    (I love the collaborative aspects too, but I think of that as a different thing than the coding type. I can pair with any language.)

    Reply
    1. Angela Post author

      Thanks, Sean.

      (Yeah, should have said long-enough-but-no-longer names.)
      (Btw, I was using the word collaborative to refer to much more than pairing. I was talking about how a shared code-base changes things, and how the whole setup–paired TDD included–results in emergent design. I’m fonding of emerging over planning.)

      Reply
  2. Conal Elliott

    I don’t have anything against (or for) OOP. I’m troubled about the continued popularity of imperative programming — a paradigm that mimics the purely sequential computers of the 1940s, rather than being tailored to high-level composable descriptions of problems & solutions, or to precise and tractable reasoning, or even to the highly non-sequential nature of modern computers.

    At least part of the reason for short names in denotative programming is that we’re often able to express extremely general notions. So we might say “map” or “fold” rather than the less general “traverse_account_records” or “add_expense_records”. Which is to say that the more general something is, the less verbiage I need to describe it (and particularly to describe what it is not).

    I hope you do scratch your itch understand and formulate Conway’s Game of Life denotatively (and elegantly). I’m happy to give you feedback and hints along the way. I bet you’ll learn a lot!

    I like the question you raise of how well denotative programming supports goals like evolution and collaborative social structures. I wonder and worry about the same. I’m guessing that the heart of the matter is not specifically denotative programming, but rather precision & rigor more generally. Perhaps rigor harms these goals through eliminating mistakes and fuzzy thinking (i.e., enforcing correctness and mental clarity) early in the game rather than late (if ever).

    Reply
    1. Angela Post author

      Thanks, Conal. You know, that last paragraph really touched me. I guess I’ll save that for later discussion though.

      Reply
  3. Luke palmer

    @Sean, just a small addendum to your comment: I think types play a bigger role in FP than in OO. This is odd since OO seems to center its ideas around creating new types. But when working with functions between immutable objects, I am constantly concerned with transforming between different representations of the same information. In order to guide this process and to make sure I don’t mix up representations, I have to use types. On the other hand, in (imperative) OO, a lot of the time information stays in one representation and I am concerned with how to ask questions about it and mutate it. This task is not as sensitive; I don’t accidentally think I’m working with a Grid when I’m working with a Scheduler. But it also makes it harder to reuse code, since I am ill-equipped to transform the data I have into the format some existing function needs.

    “If I don’t need to know how it’s done, I can just trust the object to be doing the right thing.” This brings up a major theme in my thinking recently. If you don’t need to know how it’s done, then it could be done in multiple different ways and you wouldn’t care. That is to say, your code is *abstract* — it is a *function* of the way it is done; it can be reused for any other way it is done. OO focuses on *encapsulation*, that is to say, even though you don’t need to know how it is done, it is done in exactly one way. I consider this a major weakness in any language that emphasizes encapsulation (which is most of them — the only ones that emphasize abstraction at the large scale seem to be dependently-typed languages: for example Agda and Coq).

    Reply
  4. Scott Vokes

    @Luke palmer: Types aren’t really any more mandatory with FP than they are in OO. More type research happens within the FP realm, but Erlang, Lisp/Scheme, J, and K are dynamically typed (for starters). All of them are still arguably FP, or well-suited to FP approaches. There are also plenty of dynamically-typed OO languages.

    I think it’s worth considering Erlang as an OO/FP hybrid – it discards a lot of detail required in (say) C++ or Java (much of which is only necessary due to their particular type systems), but its fundamental model is of polymorphic, encapsulated objects (Erlang processes) communicating via message-passing. Whether you prefer to think of it as very small processes running on an Erlang operating system (Unix-like) or as objects and message-passing (Smalltalk/Self-like), it works surprisingly well.

    My favorite aspects of FP-ish languages are pattern matching and composition. Both seem to be orthogonal to types: Erlang and Haskell both have pattern matching, Haskell and K both have composability.

    Reply
  5. Luke palmer

    @Scott, I’m not sure dynamically typed vs. statically typed has anything to do with my argument. Types play a role in every language. Whether those types are part of a formal compiler-checked system or an set of informal (more expressive) conventions differs from language to language. But I argue that *thinking* about types plays a larger role in FP than in imperative OO for the reasons I gave above. I admit that this may be my own mental tool and I may be overgeneralizing to other programmers.

    But think about it. When describing what a function does, I often say “it takes a _blank_ and …”. _blank_ is going to be a type, whether the compiler acknowledges it as one or now.

    Reply
  6. Philip Schwarz

    @Sean McMillan

    You said: “I’m not a fan of long names; If I have along name, it’s because I didn’t have the time to make it shorter. ;-) “.

    What a coincidence! Just before reading this blog post I had just read this other post by J B Rainsberger, in which he comments on your approach: “Long Names: a smell? or a clue?” http://blog.thecodewhisperer.com/

    Reply
  7. Philip Schwarz

    Robert West in Object Thinking:

    “Implicit in the idea of XP are other supporting ideas. Notable among these is the idea of objects. This is not surprising given that XP gurus Ward Cunningham and Kent Beck played a central role in the object revolution. They are the inventors of the CRC (Class-Responsibility-Collaborator) card approach to object analysis. The kind of object thinking introduced by Cunningham and Beck was, and is, far more consistent with the original object idea than any of the other popular approaches.

    Object thinking is central to extreme thinking. This is true even though there is little explicit mention of objects in the XP books. Object thinking is so basic to XP that it is simply assumed. As with cultural practices, it seldom occurs to members of a given culture that there is any need to explicitly talk about those practices—you simply do them the way everyone does. Many of the XP values and practices—for example, simplicity, stories, and refactoring—are dependent in important ways on object thinking.

    XP values and practices aren’t based on just any flavor of object thinking. Object thinking in XP is based on the behavior-centric ideas about objects exemplified in the CRC card approach. This approach to object thinking was always a minority view and almost disappeared as UML attained dominance and C++ challenged Smalltalk. (Visual Basic and Java superseded C++ in popularity and offered an improvement for object thinking, but still not an optimal environment.) Minority status was almost assured because of the close association of the Smalltalk programming language with behavioralism, an “informal, human-centric method” in a culture dominated by a bias in favor of formalism and engineering.”

    Reply
  8. Angela Post author

    @Scott & @Luke Thanks. I know those comments are some that I come back to, when I’m older & wiser. :)

    @Philip Interesting. I’d never seen that last one before, nor the Rainsburger. Thanks!

    Reply
  9. Evan Cofsky

    What is important to you about your preferred style of coding?

    My style comes from experimenting with writing code and then
    having to maintain it, and from using it as a centerpiece for
    working with other developers. And often to express some idea
    that has taken hold of me and needs to be expressed. Usually also
    that idea is something we’re getting paid to express, too. So
    really my style is constantly evolving, becoming more focused on
    denotative programming, or object oriented programming, and
    almost always away from the imperative elements.

    Really, what’s important to me about it is how easy it makes
    expressing things, and then understanding that
    expression. Sometimes longer names help, sometimes shorter, but
    really the names don’t often matter as much to me as actually
    understanding the code itself. And so writing the code clearly in
    a way that doesn’t require explicitly naming sections of it with
    literary flair is becoming important to me as well.

    If you’re an Agile developer, why do you love long names and TDD and objects?

    I don’t love long names or objects, yet I feel pretty comfortable
    calling myself Agile. I use objects as a way to organize code,
    but the code doesn’t serve the objects. Well, the objects also
    don’t serve the code. Really, they both serve my purpose of
    explaining what I’ve done and making it as easy as possible for
    other people to reuse my work outside of the original use and
    without needing massive amounts of effort to rework. Especially
    since often I’m the developer who will be needing it for a
    second, and even third, use.

    If you’re a Functional / Denotative Programmer, what do you love most about your code?

    I’m hardly a pure Functional programmer, or a pure Object
    Oriented programmer. But I’m not ever imperative, except where a
    language can’t be easily bent away from that. But what I really
    like about the Functional style is that it describes what it does
    so well, rather than describing how you expect things to be
    done. Really, the Imperative style that’s in vogue is not any
    different from assembly language. It’s just decorated with OOP
    keywords and structures to make it seem like something else. But
    the Functional style really is a different level of expression,
    more focused on describing problems and solutions. And when
    combined with OOP and TDD, there’s a certain amount of additional
    expressive power available to the programmer to clarify what is
    being implemented and why, without getting lost in the details of
    managing machine registers now conveniently called “variables”
    or “objects” by most imperative-style programmers.

    Can it be made collaborative in the way I’ve described?

    Of course it can. Collaboration in programming has absolutely
    nothing to do with programming style. If OOP really had anything
    to do with collaboration, then we’d see quite a bit more OOP code
    and quite a bit less “Imperative Code with Classes” running
    around.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>