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'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? (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) {
country('Australia')
record(type:'speed', 'Production Pickup Truck with speed of 271kph')
}
}
will produce this XML:
<records>
<car name='HSV Maloo' make='Holden' year='2006'>
<country>Australia</country>
<record type='speed'>Production Pickup Truck with speed of 271kph</record>
</car>
</records>
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.
sendMessage(property_name, Array of arguments) and getMessage(property_name, Array of arguments) in static languages?
– Pacerier
Jun 18 '17 at 5:08
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.
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.
