OO Do I Know Thee?

I was first introduced to the OO Programming Paradigm through JAVA in 1998.  Before that I did most of my work in C or shell scripts.  I liked it well enough but for business applications the paradigm felt wrong.  JAVA was a breath of fresh air and – at first – it seemed so natural.  I was indoctrinated into the well known 4 Concepts of OO and the whole Is A vs Has A relationships.  I dutifully created my Parent Objects which then had more specific Children (Dog Is A(n) Animal).  And it quickly began to feel as awkward as procedural programming.  In fact it was worse, because of a sense that my initial “this is so natural” reaction was correct and I must have taken a wrong turn.

This last year has seen a major shift in how I perceive what OO is and how well (or not so well) the languages I’ve used represent or support OO.  The sequence happened a bit like this:

First I went to Nothing But .Net and had many of my ideas about .Net stripped away.  It would be fair to say I left with more questions than answers but they were questions I’d been looking for since my JAVA days.

Then I learned Objective C and with it new questions around what an object is, what it does, and how are they connected.  And do they always have to be connected?

Then I started playing with Ruby and found even more questions about objects, behaviors, abstraction, and an OO application.

All of which has lead me to this – I still don’t know The Truth about OO but I have a pretty good idea what it isn’t.  A better way to say this is: I have a better idea why my initial feeling was so strong and where I diverged from the “it just makes sense” view of OO.  Some of those errors (in no particular order):

An Object is an encapsulates data and behaviors around that data.  Wrong.  Nope, not even going there.  Wrong.  Wrong.  Wrong.  This doesn’t mean an object can’t have data and behaviors.  Having and being are different things.  Don’t confuse them.

Inheritance is a parent-child relationship.  Incomplete.  The parent-child metaphor has way too much meaning and side-effects that have no place in the idea of Inheritance.  Don’t confuse them.

(C#) Interfaces are an abstract representation of a responsibility.  Too inflexible and limiting.  Narrows the scope of what they can be by (ironically) assigning them too broad a role in an application.

Abstraction is primarily expressed through Interfaces and Abstract Classes.  Perhaps that is a vehicle supplied in a particular language but Abstraction is not organically connected to any mechanism to express it.  Thinking of it in linguistic programming terms limits it’s meaning and our ability to exercise it.

I could go on to list many of the design patterns and principles you may have heard, including SOLID.  I’ve held most of these in an almost holy status at one point or another.  None of them hold The Key to OO nirvana and many of them – when viewed from an inappropriate perspective (which I often did) – can distract you from the potential and power of OO.

Lastly, from the time of my euphoric introduction to JAVA until (painfully) recently I treated OO like a sacred hammer and saw most meaningful programming challenges as eager nails.  Sad-but-true.

I now see OO as a useful paradigm to consider for human process driven applications (e.g. an application designed to mimic or assist in tasks a human would/could do).  With that broad definition I would understand people thinking I still have a magic hammer and see everything as a nail.  The reality for me is more subtle – so much so that I won’t elaborate in this post – and I’m beginning to see many problems I can solve with OO but I don’t feel I have solve with OO.

I know I haven’t supplied many answers in this post.  You don’t need my answers.  You don’t really even need my questions.  You need your own questions and your own answers.  I hope mine can help you find yours.

About Gregory Long

I'm a father, husband, and total fan of programming. I hope to share some of my journey as I learn how to do the things I love better.
This entry was posted in OO Concepts, Programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Naeem Khedarun

    Programming and Philosophy both require a logical and pragmatic approach to improvement.

    While I like that you find Object Orientation as a solution to a smaller domain of problems than most use it for, I can’t find a structured argument in your post.

    What we are looking for is not necessarily answers, but an incline pointing us in a direction of possible improvement… :)

  • I think you would really enjoy two reads on this subject (both of them older reads):

    Object Thinking by David West (http://www.amazon.com/Object-Thinking-DV-Microsoft-Professional-David/dp/0735619654) – I’m EXTREMELY surprised this is published by Microsoft (hardly anyone in the MS community has ever or does now advocate this view of OO)

    Coffee Maker by Uncle Bob Martin (http://www.objectmentor.com/resources/articles/CoffeeMaker.pdf)

    These two reads in the last year or two made me realize I don’t really know what OO is (or was meant to be), and I think I’m not alone. The Object Thinking book is great because it fills in the historical background to the OO movement (most notably Smalltalk), and where (in the author’s mind) it may have gone a little awry.

    These reads will make you ask more questions, which I suppose is a good thing. haha :)

  • @Naeem – true. true. This was mainly a ramble, but with a purpose in mind – to kick me into finishing the other posts (the ones were I present a structured idea.

    @Mike Sweet! Object Thinking has been on my future reading list for a while. Time to make it happen. I had not read the Coffee Maker but I have to say – while I agree with many of the things Uncle Bob is saying – I believe he is repeating many of the patterns of thinking about OO that I find subtly damaging. Hmmm. Maybe I should do his exercise . . . gotta think about that one.

  • @Gregory: I very much feel with you. OO to me is overrated. It´s a tool for to solve some kind of problems. And OO languages are our tools to code in.

    But why should we limited to think about solutions in OO terms?

    I´ve given that up. Instead I´m designing software using data flows – which in the end get “mechanically” translated into OO language constructs.

    The data flowing in those designs is OO in the usual way, and the leafs in the abstraction tree of my flow designs are OO code. So most of the “code” is diagrams depicting the functionality of the software in a readable manner.

    Giving up traditional OO in that way has greatly helped me and many others I´ve taught to think along the same lines. Everybody feels relieved from a great burden OO has put on them.

  • of all the statements made, i’m really interested in the the Interfaces item the most… “(C#) Interfaces are an abstract representation of a responsibility. Too inflexible and limiting. Narrows the scope of what they can be by (ironically) assigning them too broad a role in an application.”

    i’d love to see a follow-up post on this one statement, sooner rather than later. :)

    and good for you for asking questions and drawing your own conclusions. i’ve noticed myself starting to ask more questions since I’ve ventured into ruby-land. my understanding of OO is entirely .NET-centric, and I need to fix that.