Wednesday, January 19, 2005

Objects and messages in a nutshell

I do not like the term Object Oriented Programming. You can have objects all you want even in x86 assembler. Smalltalk and others, however, are much more about messages. In this light, let's consider the following:

"Consider the profound contradiction between the OOP practices of encapsulation and inheritance. To keep your code bug-free, encapsulation hides procedures (and sometimes even data) from other programmers and doesn't allow them to edit it."

No. The encapsulation part is not to keep your code bug-free, although in practice it's a desirable tendency. Encapsulation is there to allow messaging, which is the whole point of most OO languages, e.g.: Smalltalk.

Encapsulation describes how well objects are distinguished. There should be a strong boundary between the outside and the inside. In this environment, everything must happen by sending messages because messages are the only things that are allowed to cross boundaries. It is not an arbitrary decision - it's the only way to do it even if we decide to call messages something else.

Note how in Java for example, encapsulation is not as strict - and all of a sudden you are calling functions instead of sending messages! What a subtle, yet profound, difference.

If there were no clear distinctions between objects, everything would be one single incoherent blob. If there is only one blob, there cannot be a sender and a received for a message, then why send messages at all, right?

In languages in which this is allowed to occur, things happen because the programmers are thrown on some emperor's throne to rule on every bit that can possibly be addressed. This single blob is not diverse enough to route message traffic, much less reflect, on its own.

This language design trait puts the developers in the position of having to know everything so that everything that must happen inside this single blob can actually happen. But it is impossible to know everything.

Therefore, programs written within this control-oriented point of view tend to be buggier because of two big reasons. The first one is that after you are keeping 7 +- 2 things in mind, you suffer from brain overflow unless you spend time chunking. By then, you get hit with change that happens faster than you can chunk, so you can never win. The second reason is that, in addition to never being able to win, the cost of change in this environment is tremendous. Since there are no strong distinctions, there is a single incoherent blob. And in this scenario, local change can easily trigger global change and major rewrites. Not only you tend to lose - you tend to lose like Sisyphus.

Objects, on the other hand, allow you to consider constrained contexts that are easier to deal with in everyday programming. To get the maximum benefit out of this, the boundary between contexts should be as strict as possible - encapsulation. And since you want perfect continence for your contexts so there is a reasonable chance of you having to think about at most 7 +- 2 things, then you need messaging to let distinguished contexts coordinate themselves. And to allow a development style that avoids the pitfalls of copy+paste, you allow contexts to refine others by means of inheritance.

It's not that hard, really.

No comments: