Firefox/Chrome/Safari - Beautiful Examples of Objects
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 https://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".
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
I really can't see what isolation at the program level has to do with OO. That's completely independent of whether the program or language is OO, functional, imperative, or a brand new paradigm that will be invented tomorrow.
@dstar The point is not that isolation is exclusive to "$obj->method" but that if you want to say "is this object oriented" then look for isolation. Objects, in the "$obj->method" sense, objects encourage isolation by breaking everything down into pieces that pass messages back and forth to each other rather than grabbing at each other's data. Other techniques have to constantly fight their nature to be isolated.
Consider the difference between "SELECT name FROM people WHERE id = 123" and "People->get(123)->name". The former grabs at whatever it wants in the database. It can do anything. There's no control over how people are modeled, or who accesses them, or how they access them because any bit of code can grab directly at the data.
The later puts a definitive point of control over the people data. Its a gateway through which all must pass to access the data. Gateways can be controlled. Now how people are modeled can change. Now what bits of people's data are allowed out, and in what form, can be controlled. And you get it for free.
One could write "my %person = get_person(123)" but now all the %person data is just hanging out there waiting to be messed with. Or you can write heaps of SQL functions and only allow programmers to access them. Yes, you can, but its more work against the camel hair to isolate that.
You can do OO without object support, but you have to work at it, and you have to know what you're working towards. Ovid contends its messages, isolation, polymorphism.
@Schwern: note that I'm not actually contending that OO is "messages", "isolation" and "polymorphism". I am, however, leaning in that direction. That being said, it means that I've written precious little OO code, despite what most would contend. Hopefully, the Seaside and Erlang tutorials I'm taking at OSCON will help understanding some of this.
Polemic thought: genericity is more important than polymorphism.
Bizarre thought: you can't do message passing correctly without polymorphism.
@chromatic: well, if you're going to toss down the gauntlet, I must pick it up and demand satisfaction. You must defend the thesis that genericity is more important than polymorphism!
I'd like to defend that thesis, but the more I think about it, the more I decide that polymorphism tends to be what the OO people call genericity. Maybe I can sneak out of this false dilemma by claiming that they're both examples of the principle of uniform access.
@schwern: Isolation at the object level, yes, but isolation at the program level -- "any mistakes I make in my program will not crash your program" -- doesn't have anything to do with the paradigm used that I can see.
You mention that isolate can be had regardless of paradigm and I completely agree with you. I don't think Joe Armstrong is saying that only OO has isolation. He's saying that isolation is critical to have proper OO.