How exactly do “Objects communicate with each other by passing messages”?

Question

In several introductory texts on Object-oriented programming, I\'ve come across the above statement.

From wikipedia, \"In OOP, each object is capable of receivi

Answer 1

"Passing a message" is an abstraction.

Most OO languages today implement that abstraction in the form of feature invocation. By feature I mean a method an operation (see edit below), property or something similar. Bertrand Meyer in OOSC2 argues that feature invocation is the basic unit of computation in modern OO languages; this is a perfectly valid and coherent way to implement the old abstract idea that "objects communicate by message passing".

Other implementation techniques are possible. For example, objects managed by some middleware systems communicate by passing messages via a queue facility.

In summary: don't confuse abstractions with code. In the olden days, programmers used to care a lot about theory because programming barely existed as a mainstream profession. Today, most programmers are rarely familiar with the theory behind the code. :-)

By the way, and for the theory inclined, agent-oriented modelling and programming approaches often emphasise message passing as a communication mechanism between agents, arguing that it derives from speech act theory. No method invocation is involved here.

Edit. In most OO languages, you call operations rather than methods. It is the runtime engine which decides which particular method to invoke as a response to the operation that you have called. This enables the implementation of the so often mentioned mechanisms of polymorphism. This little nuance is usually forgotten in routine parlance when we refer to "calling a method". However, it is necessary in order to differentiate between operations (as features that implement message passing) and methods (as specific versions of said operations).

Answer 2

In OOP, objects don't necessarily communicate with each other by passing messages. They communicate with each other in some way that allows them to specify what they want done, but leaves the implementation of that behavior to the receiving object. Passing a message is one way of achieving that separation of the interface from the implementation. Another way is to call a (virtual) method in the receiving object.

As to which of your member function calls would really fit those requirements, it's a bit difficult to say on a language-agnostic basis. Just for example, in Java member functions are virtual by default, so your calls to a.methodA() and b.methodB() would be equivalent to passing a message. Your (attempts a) calls to b.methodA() and a.methodB() wouldn't compile because Java is statically typed.

On the contrary, in C++, member functions are not virtual by default, so none of your calls is equivalent to message passing. To get something equivalent, you'd need to explicitly declare at least one of the member functions as virtual:

class A { 
    virtual void methodA() {}
};

As it stands, however, this is basically a "distinction without a difference." To get some idea of what this means, you need to use some inheritance:

struct base { 
    void methodA() { std::cout << "base::methodA\n"; }
    virtual void methodB() { std::cout << "base::methodB\n"; }
};

struct derived { 
    void methodA() { std::cout << "derived::methodA\n"; }
    virtual void methodB() { std::cout << "derived::methodB"; }
};

int main() { 
    base1 *b1 = new base;
    base2 *b2 = new derived;

    b1->methodA();   // "base::methodA"
    b1->methodB();   // "base::methodB"
    b2->methodA();   // "base::methodA"
    b2->methodB();   // "derived::methodB"
    return 0;
}

Answer 3

They're referring to the fact that a client can invoke a method on a receiving object, and pass data to that object, but that object can decide autonomously what to do with that data, and maintain its own state as required.

The client object can't manipulate the state of the receiving object directly. This is an advantage of encapsulation - the receiving object can enforce its own state independently and change its implementation without affecting how clients interact with it.

Answer 4

Not exactly an answer to your question, but a little digression about message dispatch vs. method invocation:

The term message refers to the fact that you don't know which method will be invoked due to polymorphism. You ask an object to do something (hence the term message) and it acts accordingly. The term method invocation is misleading as it suggest you pick one exact method.

The term message is also closer to the reality of dynamic language, where you could actually send a message that the object doesn't understand (see doesNotUnderstand in Smalltalk). You can then not really speak of method invocation given that there is none matching, and the message dispatch will fail. In static typed language, this problem is prevented.