Objects When? If Ever?

  • Article

This post started as a comment on Mark Guzdial’s blog (Moti asks: Objects Never? Well, Hardly Ever!) but I decided to elaborate some. I think this is an important discussion to have both in education and in industry. Mark’s post was inspired by an article by Moti Ben-Ari Objects Never? Well, Hardly Ever! | September 2010 | Communications of the ACM. (That is premium content so if you are not an ACM member it will not be fully visible – sorry about that) The key comment from the article is probably:

I claim that the use of OOP is not as prevalent as most people believe, that it is not as successful as its proponents claim, and, therefore, that its central place in the CS curriculum is not justified.

In computer science education today it is taken pretty much as an article of faith that object oriented design is THE design paradigm to teach. The only debate most of the time is when in the curriculum to introduce it. It took me a while to grok OOP. I'm old school and remember the move to structured programming in the early 70s. There was a lot of discussion back them about having to bend designs to make them fit the “new” structured methodology. Programming  languages changed to reduce that problem but the "go to is bad" argument still remains - albeit somewhat underground. :-) But by and large the benefits were obvious enough that structured programming "won. We got a lot of good things from this change. Loops became more powerful and flexible for example. Design got easier and program maintenance got much easier.

Some say that OOP is the next step but I'm not so sure. I think it is an additional step that can co-exist with other paradigms. Proponents want to replace other ways of designing software and that is where the object first or objects later debate comes in. There is a third way that is to use objects in parallel. This argument that gets lost in the shuffle though. That is the school of thought I find myself in.

The way I see it objects fit into more traditional programs and make some things easier. Making everything an object often adds unnecessary and even unhelpful complexity to what can be simple designs. One only has to look at "hello world" written as an OOP program, say in Java. Compare that with the same in old languages like BASIC or even dynamic languages like Python. I don’t see why objects can’t be used with great efficiency when appropriate in a more traditionally designed program but always and for everything? Not so sure about that.

The problem as I see it is that objects are great tools for what they are good at but poor tools for many other things. Everything doesn’t have to be an object. Not every target in carpentry is a nail and so you need other tools than hammers. Programmers should be about having a full toolbox and not a limited one. To many people this means knowing multiple programing languages and I agree with that. I also think that programmers should be comfortable with multiple paradigms. That means functional programming as well as procedural or object oriented. It means that people should be able to use multiple tools (languages and paradigms) in the same over all project. Why not use F#( a functional language) along with C# and Visual Basic and maybe even Iron Python (a dynamic language) in the same project? Use the right tool a the right time. (This is easy with Microsoft’s .NET framework and Visual Studio of course. I’m not sure how easy it is in other tools and platforms.)

Anyway I am tired of language wars. You may want to read Old Geeks Never Die, They Just Get Grumpier on the Blog@CACM to better understand that point of view.

Comments

  • Anonymous
    September 12, 2010
    you're right, too many objects and interfaces clutters things up. A middle ground I've kind of settled with now is to let objects contain data but NOT functions..then let functions operate on the objects, not from inside the objects. In that way, objects is just a way to add new types.. So in short. use draw(monster) and not monster.draw(). I found out that Scala with it's "traits" suits this way very nice. Anyway, just my 50.

  • Anonymous
    September 12, 2010
    Objects are a good way of managing some kinds of solutions. They are also a good way of abstracting detal that you don't want to bother with while you do the top level design. And they are a great way to deploy related resources. But they are a horible way to teach programming. I once tried to teach programming in an "objects first" way and got a bunch of people who could draw lovely class diagrams but couldn't get anything to work. Never again. We now spend a very big chunk of our teaching getting algorithms sorted, and then introduce objects as a solution to problems of organisation and specification. And I always encourage my students to remember that the customer doesn't actually care what technologies you have used to make it work, they just want a happy ending.