My introduction to object-oriented programming
The first time I heard about object-oriented programming I was at a point in my learning where I didn’t question the why of things very much. I was too busy taking in the huge amount of stuff I had to learn, and I just tried to swallow it all without getting indigestion, which was hard enough. Let’s say I was deep in “Shu” and learned mostly by imitation.
That’s why for a long time, OOP to me was basically repeating the same mantras over and over: classes, encapsulation, inheritance and polymorphism.
Over time I found out that these mantras belonged to the “style” of OOP that Bjarne Stroustrup proposed in C++, carried on by a whole cast of derived languages.
Rediscovering object-oriented programming
Once I got past the phase of swallowing information indiscriminately, I found there were other points of view on what object-oriented programming was. You can find completely different definitions, and nuances on the usual definitions I was used to hearing.
One of the first surprises was finding out that the definition of object-oriented programming given by the person who coined the term in the 70s didn’t mention the words encapsulation, inheritance or polymorphism:
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things.” - Alan Kay
An example of a language that follows this definition faithfully is Smalltalk, created by Alan Kay himself, among others. If we move from the vintage universe to something a bit more used nowadays, we find Objective-C or Ruby.
Funnily enough, this definition fits the actor model perfectly; I think you can see its influence. Still, the actor model presents itself as a model of computation and object-oriented programming as a development paradigm, so they have different scopes.
Looking for consensus
In 1995 Meilir Page-Jones wrote the book “What every programmer should know about Object-Oriented design”. In the book, Meilir talks precisely about the lack of consensus on the definition of object-oriented programming, and tells an anecdote that I’m going to try to retell, taking a lot of liberties:
A few years ago, I decided to settle the matter once and for all. I grabbed a dozen experts from the object-oriented world and locked them in a room with no food or water. I told them I’d let them out only when they had agreed on a definition of object-oriented programming that I could publish.
After an hour of shouting and banging in the room, there was silence. I went into the room fearing the worst […] and found the gurus alive, although they were no longer speaking to each other.
Apparently, each guru had started the session trying to establish a definition of object-oriented programming and, after getting nowhere, they had agreed that each one would list the properties they considered indispensable in an object-oriented environment. Each of them had come up with a list of between 6 and 10 indispensable properties.
At that point, instead of creating one big list by merging them all, they decided to create a list with only the words common to every list. The result was a list with a single word: “encapsulation”.
The rest of the story is interesting, but I’m not going to translate the book in this post. If you’re interested, you can buy it ;)
Anecdotes aside, what seems clear is that reaching a consensus on what exactly object-oriented programming is turns out to be hard. My opinion is that in the end we adopt the consensus set by the programming language we’re using.
Looking for a style
When we say object-oriented programming is a development paradigm, we’re assuming there’s a defined style, a set of patterns and features provided by the programming language we use, that will guide us and define the way we should develop.
That’s all very nice, but nothing could be further from reality. Within object-oriented programming there are many styles and many ways of interpreting the paradigm. And not only between different languages, but also within the same language. That’s why over the years certain patterns and good practices have taken hold, although some are still “a matter of taste”.
My plan is to describe, in a series of posts, how I currently understand OOP and how I apply it in C#. I really liked some of the explanations in Meilir Page-Jones’s book, so I’ll probably use them as a common thread. I don’t know if it’ll be two posts or 20; I’ll keep writing as long as I have the time and the urge ;)
The cover image comes from this Dilbert strip