What is message passing in OOP?

Question

I am interested in message passing, generally.

I read few definitions but it's still completely unclear and abstract to me what it really means.

Now, here is where it's struck me that MP is crucial...

Class-based Object-oriented programming languages support objects defined by their class. Class definitions include member data. Message passing is a key concept (if not the key concept) in Object-oriented languages.

So, could someone explain me what is message passing in (as much as possible) clear English with some analogy or some examples.

I do have about a year experience in programming, but mostly on CodeAcademy, plus various books, youtube videos and Wikipedia articles.

Answer 1

Imagine that you have two objects. Picture them as iron boxes. They have all sorts of mechanics and logic within them, but you can't see it from outside the boxes. They encapsulate that logic. To an outside observer (such as each other), they are a "black box".

These boxes do have some observable (and interact-able) attributes and operations. Maybe they have little indicator lights that tell you something (public properties), or they have buttons which do something internally (methods) and change the state of those lights.

Box A knows about Box B. It holds a reference to it. In this analogy, it basically has some mechanical interface which can reach over to Box B and press buttons on it. Box A knows that Box B can do a particular thing that Box A wants to happen. Box A can't reach inside of Box B and use its logic (mechanics) to do the thing itself. That would violate the encapsulation and would make Box A too dependent on Box B.

(This is because Box A isn't actually depending on Box B's internal mechanics at this time. It's only depending on the interface. If you were to build an entirely new Box B-1 which has entirely different ways of doing the things it does, but is contained in the same iron shell with the same buttons and lights, Box A never needs to know about that. Both Box B and Box B-1 expose the same interface and so their internals don't need to be known.)

Instead, Box A needs to send a message to Box B. Let's say that Box B needs some information in order to do the thing. (Imagine, for example, a credit card reader or something like that. The box internally does a thing, but it needs some data from an external source first.) When Box A invokes this operation on Box B, it provides this information. (It's calling a method on Box B and supplying a parameter to that method.)

If the operation has a return value, then Box B (or Box B-1, it doesn't matter) responds with that information. Effectively passing a message back to Box A (or whoever invoked its operation, it doesn't matter).

---

It's kind of a complex analogy to describe what is essentially just, well, calling a method. But in most cases, that's exactly what it is. There are more complex cases, and there are languages which do more interesting things. For example, there are scenarios where the structure of the message might not necessarily be known. As opposed to a Java/C#/etc. method signature where the structure is statically known.

But in the end, basically what you have are encapsulated objects invoking operations on each other, sending information to those operations, and receiving information from those operations.

Answer 2

In an object oriented approach, objects do things themselves. A "message" is the terminology used when telling an object to do something.

The opposite is a procedural approach, where code gets some information elsewhere, and then acts based on the information provided.

Consider the diagram at http://aryehoffman.com/reference/action-object-principle/