You may not have heard of Ralph Johnson and Joe Armstong, but they've been programming longer than most of us have, including OO programming longer than most of us have. It's fair to say that after you've been doing something a while, you tend to form opinions about it. Mssrs. Johnson and Armstrong have opinions and this interview with Ralph Johnson and Joe Armstrong is full of said opinions. It's brilliant. There's a great bit from Joe Armstrong where he explains what he thinks "OO" should be about. Though he doesn't use the Web browser as an example, I will. But first, it's important to quote him at length.

The 3 things that object oriented programming has it's messaging, which is possibly the most important thing. The next thing is isolation and that's what I talked about earlier, that my program shouldn't crash your program, if the 2 things are isolated, then any mistakes I make in my program will not crash your program. This is certainly not true with Java. You cannot take 2 Java applications, bung them in the JVM and one of them still halts the machine and the other one will halt as well. You can crash somebody else's application, so they are not isolated.

The third thing you want is polymorphism. Polymorphism is especially regarding messaging, that's just there for the programmer's convenience. It's very nice to have for all objects or all processes or whatever you call them, to have a printMe method - "Go print yourself" and then they print themselves. That's because the programmers, if they all got different names, the programmer is never going to remember this, so it's a polymorphism. It just means "OK, all objects have a printMe method. All objects have a what's your size method or introspection method."

To summarize, Armstrong asserts that OO is about:

Messages

Polymorphism

Isolation

Forget for a moment whether or not you agree with this, just consider the implications. Note that we're not talking about classes, prototypes, code reuse, inheritance or syntax. Those are implementation details. We're talking about "what", not "how".

Messages

I'll use a Web browser as a perfect example of this. First, messages are not method calls. Object A sends a message to Object B and Object B is free to respond or not. If Object A is a Google Chrome browser, the "message" it sends to a Web server might be:

GET /users/ovid/2010/07/firefoxchromesafari---beautiful-examples-of-objects.html

The Web server can choose to response or not. If you're making that request to http://blogs.perl.org/ , you probably will get a 200 response and find yourself reading this blog entry. If you make that request to reddit.com, you're probably going to get a 404 and not read this blog entry. Either way, you can choose to send this message.

Polymorphism

This leads us to the next point. You can send the same message to multiple objects. If they choose to respond to this message, you should be prepared to handle it and Web browsers generally are. In the "message" example above, the browser will likely wind up rendering content in both cases, but for a clearer example, consider GET / . Virtually every Web server can and will respond to that. They may respond with a 200 and the "home page", or they may choose to respond with a 30x redirect, forcing the browser to make a decision on whether or not to follow said redirect (different browsers behave differently here). In any event, the fact that almost all Web servers will respond to GET / , but may respond in different ways, is a perfect example of polymorphism.

Isolation

Some people think this means encapsulation, but that's only part of what's happening. Imagine that you're being naughty and trying to exploit an SQL injection attack on someone's Web site. In the process, you might crash their Web site. You did not crash your browser (or command line user-agent or whatever tool you're using). Isolation means that separate objects have no direct impact on one another, short of how they choose to handle sending and receiving messages.

So is that really OO?

This is, admittedly, not a way of looking at OO that comes naturally to most programmers. Whether this is due to genuinely differing opinions or staying in our comfort zone is for others to argue. Even when I tell people how great Moose is, I have to keep in mind that it's only one interpretation of how OO should be. Thus, when people say things like REST is what OO design should be, it's easy to get confused about what is meant, but when you think about messaging, isolation and polymorphism, things become much clearer. It also becomes clear that most "OO" languages would struggle to fit this view of "OO".