Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I have read that in OOP, we think of objects as "sending messages to each other", for example if we did car1.stop(), we say that "we sent the message stop() to the car1 object".
But what benefit do we get by thinking of objects as "sending messages to each other?" What I mean is, let's say that we thought of car1.stop() as "calling the method stop() on the car1 object." What's wrong with thinking of it like this?
It avoids micromanaging.
If I tell you to stop in an OO way I haven't called your stop procedure, or your stop function, or your stop method. When I send that stop message I've raised a stop event. One that you are free to handle or not. You don't even have to respond. Now sure, you might use a stop method to handle that, but that's your problem.
This avoids micromanaging because I don't have to deal with how you respond to being told to stop. I don't have to think, "OK I told him to stop, now what's he going to do? If he ignores me then I'll do this, if he has a problem then I'll do that, if he stops then I'll do this next thing". No, that's micromanaging. If anything needs to be told what happened when you got told to stop it's better to let you decide who to tell. It gives me fewer things to think about. It gives you more freedom to control your stop response.
This keeps a very low form of coupling between objects. Lower even than typical1 functional programming. Functional programming does composition beautifully. Pure functions make reasoning simple. But it locks you down to sending the response back to the caller. It has nowhere else to go. That couples caller to callee. Messages, however, can go where they've been configured to go without worrying what becomes of them. It's not as straightforward but it's another detail avoided.
Another benefit is minimizing data movement. Functional programming has been called "data in, data out". OOP wraps data in a "message in, message out" system. The messages can be very lightweight compared to the data.
I'm contrasting OOP with Functional here but that shouldn't be taken to mean you exclusively use one or the other. Many of functional programmings principles can be used while using OOP. Prefer immutable objects. Be disciplined with side effects. Etc.
OOP messaging is a powerful way to model. It inherently respects encapsulation. I don't look inside you. I don't ask you about your privates. I tell you what I want done and you decide what, if anything, to do about it. Once I tell you, I don't have to hover over you and manage what you do. I just let you do it. Whatever it is. If I ever need to know more I'm sure someone will tell me.
Messaging is sometimes implemented by using methods as the messages but that's just one way to do it. It could be text messages, packets, tweets, emails, etc. The methods are not what makes it OOP. It's how you use them.
Here's the rub. Just because you're using an “OOP language” that has methods doesn't mean every method is a genuine OOP message. No language perfectly enforces this. Your programming team has to enforce this. Depending on the design, a method may conform to requirements of a OOP message. If you're lucky your core packages will follow this well. I've never worked on a project where OOP was 100% enforced or a functional project where everything was pure. But the better projects will find some way to at least signal clearly where the ideals are followed and where they have been compromised. This is important because it impacts the readability of the code. It's good to quickly know if you're looking at a true OOP message, a pure function, or some other monster.
Joel has blessed us with this awesome comment:
1. Regarding Functional Programming only returning to the caller, I would suggest looking into the technique continuation passing style combined with tail call optimization. "When you're done here, talk to this other guy. I will show myself out." – Joel Harmon
This is all true. But if the caller is saying "talk to this other guy" the caller is still dealing with knowing where to send the response. To put functional programming coupling on par with OOP (that configures output ports in constructors) pass "this other guy" into the enclosing scope of a closure. That way the caller neither knows nor cares where the result goes.
car.stop(); pedestrian.crossRoad(); <- what do you think happens if the car doesn't stop? What would your liability be if you designed a system where the car can ignore your request? (you might say we should check car.isStopped, but of course it returns true, because it would be "micro-managing" if we cared whether it told the truth)
Oct 15, 2020 at 11:15
None.
Not sure where you are reading this idea of objects sending messages, but if it is the same as this question, So what *did* Alan Kay really mean by the term "object-oriented"?, then it's pretty clear that the inventor of the term Object Orientated is talking about passing messages in a way that today's OOP languages just don't do.
So it may be useful if you are programming in Smalltalk, or writing event driven code, but not if you are talking about today's accepted meaning of Object Orientated Programming, which has methods - not messages.
If you call car.stop() you aren't sending the stop message to car and carrying on with your life, maybe getting a message back at a later date. You are "going to" the code in the stop method, running each statement in turn and returning a result back to where you left off.
The answer may be quite simple: "Sending a message", unlike "calling a method", is using a language which is understood outside of the software domain. When explaining abstract concepts it is always good to use words from another domain which the audience has an understanding for.
In addition to the points that candied_orange made, this concept is highly useful in for multi-threaded and concurrent systems. In such systems, you can't depend on the notion that when you call a method that it will be the next thing that happen in your program or that the calls will even execute in the order they were called. Doing so will lead to race conditions and other problems.
It's helpful instead to think about method calls as a message to another object that it will receive sometime later, perhaps after some other message has been processed. This model can help produce robust systems without relying too heavily on locks which can create contention and hobble performance.
I think this may mainly be due to the history of object-oriented programming. Some of the early OO languages had syntax that explicitly used messages.
Smalltalk described its operations as messages, using a syntax like:
car1 stop
And in Lisp Machine Lisp Flavors you would write
(send car1 ':STOP)
As you can see here, the message argument is an expression (since it needs to be quoted above), so you can abstract it away in a variable.
(let ((msg (if (some-condition) ':START ':STOP)))
(send car1 msg))
Of course, these are isomorphic to function calling, and CLOS dropped the explicit message passing syntax in favor of generic functions with no loss of functionality. And you can accomplish dynamic message passing with first-class function objects.
But many programmers still like to think of this as message passing, because one of the principles of OOP is that each class takes responsibility for how it implements actions. Calling a method is considered to be telling the class of the object to take an action, and that seems analogous to passing a message to an autonomous actor ("actors" and "messages" are also common in many asynchronous programming models).
carl stop syntax "explicitly used messages" whilst carl.stop() doesn't. Both can be understood as either a lookup ("Which stop should I run? The carl stop") or as sending a command/message ("Carl. Stop!")
I think the 5 answers have missed the point. Let's admit one thing to start off. Whether it is called a message or a function it is just code that gets executed.
Function and subroutine had long been used before method was coined. So why was a new word needed? Because both function and subroutine call very particular pieces of code. Thinking of the call as a message allows a new paradigm.
With inheritance you don't know where the method is actually implemented. Let's say that in this case that car is a child of vehicle and it is vehicle that first implements the stop message. Thus car doesn't have to implement a new message. Car inherits the code to implement the stop message from vehicle.
However let's say that we also have a amphibious_vehicle which is also a child of vehicle. Now vehicle's stop method is assuming braking on dry land by sending a message break(0) to itself. Brakes work on land, but don't work on water. So while in the water something different is needed for amphibious_vehicle.
But this means that all vehicles will understand stop() regardless of how the particular child of vehicle may override vehicle's code for the method.
In the olden days, sending a message in C++ or Objective-C was indeed just a glorified function call. Admittedly the call was dynamic, so you didn’t have to figure out which function body to call, just the method name, but under the hood it was just a function call.
That has been changing in the last years, at least where I work. There are so many things where you cannot just call something and wait for it to happen. Just a plain URL request: It can happen in a few milliseconds, but even that is too slow to waste the time waiting for it. But it might time out after 60 seconds. It might detect there is no WiFi and ask the user to turn WiFi on. It might run into errors that can be fixed by retrying. This is all so complicated, you can’t just make it a function call and wait.
Now the message metaphor works really well. Instead of ordering “download that URL” and waiting for the result, you send a message “I’d like that URL, please”. You continue what you were doing, and eventually someone will send a message back to you, either reporting the contents of the URL or reporting an error. And at that point your whole situation might have changed; you wanted to download an image and display it, but meanwhile the user switched to a different page! With a plain call, that wouldn’t have been possible.
The "messages" metaphor helps you in creating well-designed classes, encapsulating their internals. But it's a metaphor, one specific way of viewing object-oriented software.
The metaphor of a lot of employees (instances) doing different jobs (classes), and communicating by sending messages and waiting for answers more naturally tends to create a structure where the message types are well designed and grouped according to the jobs of the recipients.
In this metaphor, for every message type, you have to decide on some very useful aspects:
Of course, method calling is an absolutely valid view of object-oriented software. That's what happens at the core of object-oriented software. And of course you can ask all the above questions with a method-calling terminology as well.
But the method-calling view can more easily put the method into focus with its procedural content and ignore the "responsibility" aspect.
Have you ever found yourself thinking along the line:
Oh, I need to do X [e.g. print some nicely-formatted currency amount] here. Wait, I've done this in the Y [e.g. BankAccount] class, so let's just create a Y [BankAccount] instance, have it print the value, and then forget about it.
From a procedural view, that's fine, but really bad object-oriented design.
The "messages" metaphor and the questions that it naturally brings along, help me not to fall into this trap.
Here are some linguistic reasons.
Firstly.
When there are no parameters, there isn't a lot of daylight between
But, when you have arguments (e.g. Z.X(Y)), we can think of X(Y) as being the message. To say "Call method X(Y) of method Z" is wrong because X(Y) is not a method. We have a choice between.
I prefer the former because it lets me talk about X(Y) as one linguistic unit, which I call the "message".
Secondly.
"X" is not a method, it's a name. In a non-OO language, this distinction isn't that important. If a Fortran programmer says "Call subroutine X", it's clear that they mean "Call the subroutine whose name is 'X'". That's the whole point of names; we can use them in place of a named thing, because each name should identify one and only one thing (in each context). But, in an OO language, there isn't typically a single method with name "X"; "X" might be the name of an abstract method and also of various concrete methods; so saying "Call the method whose name is 'X'" doesn't make sense and nor does "Call method X" and nor does "Call method X with argument Y." I have to say the "of object Z" part; and that is sometimes inconvenient.
Thirdly
Saying "Call method X of object Z" makes it seem like the only role of Z is to provide a context in which to interpret the name "X"; and once it's figured out which method named X is to be called, the machine just goes ahead a calls it as if it were any other subroutine. But, that's not what's going on.(*) Z is used not only to find the method, but also it also plays the role of the recipient. So to be precise we need to say something like
As an instructor, I worry that the message sending metaphor can easily lead students astray. I use it, but I try to help the students understand that underneath it all, whether you call them "message sends" or "method calls", it really is just a kind of subroutine call.
(*) In some languages, an expression Z.X(Y) might be considered equivalent to (Z.X)(Y), where Z.X is an expression that evaluates to a closure that can be applied like any other closure. But this is not how method calls (or message sends) in most OO languages work.
We understand messages to be:
And we know that about message passing from lived experience.
Functional Calling though evokes directly talking to someone face to face: Instantaneous, Direct, Real time, no wait, Two-way dialogue, with every side-effect apparent to the observant.
The most commonly used OO languages we have today, things such as C++, Java, C#, do not do what Alan Kay originally thought of:
I was too blythe about the term back in the 60s and should have chosen something like "message oriented" – Alan Kay Jun 8 '11 at 16:27
by which he means actual data messages, not method calls.
So in the context of the above languages, not only is there no benefit in thinking of objects as "sending messages to each other", it is actually dangerous, especially in multi-threaded and parallel systems, due to the difference between sending an actual message, and performing a method call. Call stacks do not cross threads, so cannot correctly model call chains in those circumstances.
Carl Hewitt defined the Actor Model, which introduces actual message passing as a work-around in those languages which do not inherently support actual messages.
