I've been studying OO programming, primarily in C++, C# and Java. I thought I had a good grasp on it with my understanding of encapsulation, inheritance and polymorphism.

One frequently referenced concept when discussing OO is "message passing". Apparently, this is something that is not used whilst OO programming in today's mainstream languages, but is supported by Smalltalk.

My questions are:

  • What is message passing?
  • Is there any support for this "message passing" in C++, C# or Java?
  • 4
    I answered this question on SO a while ago: stackoverflow.com/a/3104741/10259 Mar 20, 2012 at 8:10
  • 1
    Did you read the Wikipedia article?
    – yannis
    Mar 20, 2012 at 8:11
  • 4
    In my humble opinion, Objective-C would qualify as a mainstream language. At least as much as C#.
    – mouviciel
    Mar 20, 2012 at 8:49
  • I agree with that, I was stating the "mainstream" languages from my experience
    – Tom
    Mar 20, 2012 at 11:42
  • A member function call is one implementation of passing a message. The message passed is identified by the function name, and includes the information from the parameters. Late binding allows the receiving class to handle the same message in a different way to other classes. It's not what was intended by the creators of Simula, and many people would object to calling it message passing and state (with good reason) that doing message passing is a key thing that makes Simula different, but member function calls still do essentially the same job.
    – user8709
    Mar 20, 2012 at 12:42

3 Answers 3


What is message passing? (Can someone give a practical example?)

Message passing simply means that (at a very abstract level) the fundamental mechanism of program execution is objects sending each other messages. The important point is that the name and structure of these messages is not necessarily fixed beforehand in the source code and can itself be additional information. This is an important part of what Alan Kay originally envisioned as "object oriented programming".

Is there any support for this "message passing" in C++, C# or Java?

These language implement a limited version of message passing through method calls. Limited because the set of messages that can be sent is limited to the methods declared in a class. The advantage of this approach is that it can be implemented very efficiently, and it enables very detailed static code analysis (which results in all kinds of useful benefits, like code completion).

Conversely, languages that implment "real" message passing often have method definitions too, as a convenient way to implement message handlers, but allow classes to implement more flexible message handlers that enable the object to recieve "method calls" with arbitrary names (not fixed at compile time).

An example in Groovy that demonstrates the power of this concept:

def xml = new MarkupBuilder(writer)
xml.records() {
  car(name:'HSV Maloo', make:'Holden', year:2006) {
    record(type:'speed', 'Production Pickup Truck with speed of 271kph')

will produce this XML:

  <car name='HSV Maloo' make='Holden' year='2006'>
    <record type='speed'>Production Pickup Truck with speed of 271kph</record>

Note that records, car, country and record are syntactically method calls, but there are no methods of that name defined in MarkupBuilder. Instead, it has a catchall message handler that accepts all messages and interprets the message names as the name of an XML element, parameters as attributes and closures as child elements.

  • +1 straight to the point answer. Accepted for the code example. Thanks for your help :)
    – Tom
    Mar 21, 2012 at 15:16
  • So couldn't it simply be implemented with a simple sendMessage(property_name, Array of arguments) and getMessage(property_name, Array of arguments) in static languages?
    – Pacerier
    Jun 18, 2017 at 5:08
  • 1
    @Pacerier: sure, but that's combining the disadvantages of both approaches - you lose type safety and still have "sendMessage" polluting you code everywhere, so you don't get the elegant syntax. Jun 18, 2017 at 19:25
  • Would it be more correct to say that, in the Groovy example, the message handler is receiving a message, rather than a method call? You initially put quotes around the phrase "method call", but in your last sentence, you say that it "accepts all methods", rather than "messages". Jul 6, 2017 at 1:12
  • @AdamZerner: you're right, I fixed it. Jul 6, 2017 at 6:48

Message passing is a different way of handling the need in OO code for one object to get another object (or potentially itself) to do something.

In most modern languages that descend from the C++ approach we do that with method calls. In this case the called object (via its class definition) puts a big list of what method calls it accepts and then the coder of the calling object simply write the the call:

public void doSomething ( String input )
other_object.dosomething ( local )

For statically typed languages then compiler can then check the type of the thing being called and confirm that the method has been declared. For dynamically typed languages then that is carried out at runtime.

But in essence what happens is that a bundle of variables is sent to a specific block of code.

Message passing

In message passing languages (such as Objective C) instead of methods there are recievers, but broadly the approach of defining them and calling them is much the same - the difference is the way its handled.

In a message passed language the compiler may check that the receiver that you've called exists, but at worst it will pop up a warning to say it's not sure that its there. This is because at run time what will happen is that a block of code on the receiving object will be called passing both the bundle of variables and the signature of the receiver you want to call. That block of code then looks for the receiver and calls it. However if the receiver doesn't exist then the code will simply return a default value.

As a result one of the oddities found when moving from C++/Java -> Objective C is understanding that you can "call a method" on an object that wasn't declared on the compile-time type, and didn't even exist on the run-time type ... and that the call would not result in an exception being thrown but in fact a result being passed back.

The advantages of this approach are that it flattens the subclass hierachy and avoids most of the needs for interfaces/multiple inheritance/duck types. It also allows objects to define default behaviour when asked to do something that they don't have a receiver for (commonly "if I don't do it, forward the request to this other object"). It can also simplify the linking to callbacks (e.g. for UI elements and timed events) particularly over statically typed languages such as Java (so you can have the button call the receiver "runTest" rather than call the "actionPerformed" method on the inner class "RunTestButtonListener" which does the call for you).

However it would seem to be at the cost of the need for additional checking by the developer that the call they think they are making is on the right object with the right type and passing the right parameters in the right order, because the compiler might not warn you and it will run perfectly well at runtime (just returning a default response). There is also arguably a performance hit from the extra look-up and paramter passing.

These days, dynamically typed languages can give a lot of the benefits of message passed OO with less of the issues.

  • 1
    I like this answer - explains the differences and their implications.
    – Arjailer
    Dec 1, 2012 at 21:19
  • 1
    @Gavin, So is it exactly the same as PHP's and Javascript's dynamic method handler?
    – Pacerier
    Jun 18, 2017 at 5:06

Message passing architectures are simply systems where each component is independent of the others, with a common mechanism for passing data between them. You can consider method calls as a form of message passing, but it's not practical to do so - it confuses the issue. This is because if you have a class with well-defined methods, and some code that calls those methods, the entire thing must be compiled together, thus coupling the code and the object. you can see how it is close (as a message is being passed, and the compiler is enforcing correctness, but it loses much of the flexibility of a decoupled system).

Message passing architectures often allow objects to be added at runtime, and more often than not allow messages to be redirected to one or more objects. So I can have some code that broadcasts a 'data x is updated' message to all objects that have been loaded into the system, and each one of them can take whatever action they like with that information.

A weird example is the web. HTTP is a message passing system - you pass a command verb and a 'data packet' to a server process. (eg GET http:\myserver\url) Neither your browser, nor the webserver cares anything about the data you send, or where you send it to. The server will pass it on to the code that will package up another 'packet' of data and send it back to you. None of the component in this system know anything about the others work or what they do, they just know the protocol used for the message communication.

  • @gbjbannb, Need some pseudo code explanations....
    – Pacerier
    Jun 18, 2017 at 5:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.