The role of culture - and what's an object?

I had an interesting thought today. Why do you eat of plates? Our dining table is covered by a fine oilcloth, why don't we eat of that?

The plain answer, I think, is that we've been taught when we were young to use plates, to the point that it even seems unhygienic not to do so. Imagine a dinner with meat, potatoes and a batch of sticky sauce on your dining table.

Image by ayalan

If you're looking for deeper reasons for why one eats of plates it's probably easy to find out. Just have a dinner directly on your table. I suspect the reasons have something to do with the difficulty of cleaning up afterwards and sharp knives and scratches in the surface.

Pottery is a pretty old technology. The point is that it's part of our culture, we never think about it, we just do it. But it's one of the million of things that make up the great technological advancements civilisation has made over the past centuries. If we weren't able to absorb them, if we had to think about all of them, we would never have gotten anywhere.

A similar thing goes on in software. With a programming language you can build anything you can think of, provided you have the hardware to run it on. But still it takes time to invent new things. Old things have to be absorbed into our culture before we can move on, otherwise the leap is too great.

Of course behaviours that once have been embedded might stop making sense as the environment changes, unnoticed. When you dig into it the reasons stop being reasonable. I think you'll find that traditions and rituals provide a rich source of examples of this phenomenon - it made sense to those who concocted it, but 50 years later it's really silly when you think about it. Of course, that might not stop you from enjoying it.

Image by Thomas Hawk

In any case, I think it's sometimes interesting to turn things we take for granted upside-down. Today I've been thinking about the corner stone of object-oriented programming. Let's be pragmatic. What's an object?

You might think of attributes and methods. My take on it is that it depends.

In some types of code, it's a very useful modeling utility.

For instance, just think of the string class in your favourite programming language. It encapsulates most of the stuff you'd want to do with a string in a neat little package you can easily instantiate as many of as you like. If you've ever tried the horror that is the built-in string handling in the C standard library (not to pick on it, it was probably fine for its time), you'll really appreciate that. You might miss the occasional method or two, but still, it's very useful and easy to understand.

Library code is full of neat little packages like this. Dynamic arrays, linked lists, HTTP handling, database connections, widgets in a graphical toolkit.

As you go to application code, the answer is in many cases less clear cut. To a certain extent, this is perhaps because the concepts are less understood or perhaps just less well-defined.

In my applications I find that I have objects that are more or less just data (plain old data, PODs as they call them in C++ lingo) and objects that aren't really objects that I instantiate, let do a well-defined job and then throw away, but more of the sort of puppeteers or glue. These are all objects that give me head-aches. I also find some objects that are like the library objects, neat little packages. These are usually a great relief.

The first type of objects, typical application objects, are troublesome because they go against the culture of object-oriented programming. Which says that you shall divide your code into neat little interacting packages with methods and encapsulated attributes, instantiated and used dynamically.

But if we step back, then what's the purpose of objects? As I see it, it's a way of organising code. Think of it as a hierarchy. At the lowest level, you have the individual lines of code. We organise them into functions which let us deal with perhaps 10-100 times the amount of code, still maintaining an overview, like the headlines in a newspaper that groups the thousands of lines of text into articles.

Image by jurvetson

As a program grows, you need another level, one that will give you 10-100 more code without losing the grip of the program. This is plain hierarchy theory. Look at the folders on your computer for a prime example. An object is one such next level, one that is more flexible out of the box than traditional function library modules because it has state.

However, just because you need another level, it doesn't mean that the code will fit well into the object-oriented thinking of a neat little package where the data is encapsulated inside. I personally think it's impossible in many applications; otherwise it's going to take a lot of hard thinking, and I mean really a lot, because I have often wasted hours trying to find a way out of my crippled semi-objects.

It is true for the plain old data structures. In many cases, you just need to group a set of attributes under a name without the functionality making use of the attributes logically or even illogically belonging to the grouping. So just put them in, recognising this as a case where the object thinking is useful but not a 100% fit.

If you're writing getters and setters for this kind of stuff, you're wasting your time serving the culture of object-oriented programming as it was taught to you.

The same goes for glue code. It may organise the code better to put it inside an object. If so, go for it even if you're never going to do typical object stuff with it.

In any case, as I see it the goal here is a well-organised program. A well-organised program is obviously easier to understand, and thus easier to work with, extend, fix bugs in, etc. Think about that and forget culture next time your wrestle with program design and nothing seems right.