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

What you have posted will not compile in any oop language, as methodB does not belong to object A and methodA doesn't belong to object B.

If you called the correct method, then both of these are message passing by object C:

a.methodA();
b.methodB();

From wikipedia:

The process by which an object sends data to another object or asks the other object to invoke a method.

Answer 2

Some of the early academic work on OO was in terms of objects passing messages to each other in order to invoke behavior. Some early OO languages were actually written that way (SmallTalk?).

Modern languages like C++, C# and Java do not work that way at all. They simply have code call methods on objects. This is exactly like a procedural language, except that a hidden reference to the class being called is passed in the call ("this").

Answer 3

Does that code works?

Anyway you're out of the road...

Message passing is a way for interprocess communication, one among many others. It means that two (or more) object can only speak one each other by messaging, which should say from who, to who, and what...

You can see it's very different from shared memory, for example...

Answer 4

Your example won't work with Java or Python, so I have corrected and annotated your main

class C{
  main()
  {
   A a=new A();
   B b=new B();
   a.methodA(); // C says to a that methodA should be executed
   // C says to b that methodB should be executed
   // and b says to C that the result is answer
   answer = b.methodB(); 
  }
}

Answer 5

passing object as parameter to a method of an object that belong to a different class type. this way you pass attribute of an object to another object of a different class just call an methods of a object of an other class. so you can create an object of this class to get information of other object of different class. Note: this no override methods ok because they can be the same name but belong to a different class type. override methods is went you heritage a methods in a sub class and you change the behavior of the same methods that you get for heritance of a super class. the method to call is depending of arguments that you put in the method or the data type. the system call the right method and they can be located in a object of a superclass or in a object of a subclass.

a lot of people ask the same question. when they are working with OOP. I recommend read those old books. to understand what is OOP and not learn to programming object oriented in a programming language as CPP, JAVA and PHP. introduction to OOP (Timothy Buud) Object-Oriented Programming: An Evolutionary Approach (Brad J Cox . Andrew J Novobilski) and not forget to read Bjarne stroustrup CPP new books.

#include <iostream>
#include <string>
using namespace std;

class Car{
string brand;   
public:
void setBrand(string newBrand){this->brand=newBrand;}
void Driver(){cout<<" IS DRIVING THIS CAR BRAND "<<brand<<endl;}
void Brake(){cout<<"IS BRAKING"<<endl;}
};

class Person{
private:string name;
public:
void setName(string newName){this->name=newName;}
//HERE WE CALL METHOD OF CAR CLASS AND REDEFINE METHODS NO OVERRIDE OK   
void Driver(Car objectOfClassCar){cout<<this->name<<ends;  
objectOfClassCar.Driver();}
 void Brake(string str, Car objectOfClassCar){cout<<this->name<<"  
"<<str<<ends;objectOfClassCar.Brake();}
  };

  int main(){
  Car corolla;
  corolla.setBrand("TOYOTA");   
  Person student;
  student.setName("MIGUEL");
  student.Driver(corolla);
  student.Brake("CAR",corolla);
  //it open a lot of opportunities to do the same.
  }

Answer 6

If we are talking about OOP than the term "message passing" comes from Smalltalk. In a few words the Smalltalk basic principles are:

1. Object is the basic unit of object-oriented system.
2. Objects have their own state.
3. Objects communicate by sending and receiving messages.

If you are interested in Smalltalk take a look at Pharo or Squeak.

Java/C#/C++ and many other languages use slightly different approach probably derived from Simula. You invoke a method instead of pass a message.

I think this terms are more or less equivalent. May be the only interesting difference is that message passing (at least in Smalltalk) always rely on dynamic dispatch and late binding while in the case of method invocation one can use static dispatch and early binding too. For example, C++ (AFAIK) does early binding by default until "virtual" keyword appears somewhere...

Anyway, regardless of which formalism do your programming language use for communication between two objects (message passing or method invocation) it's always considered a good OOP style to forbid direct access to instance variables in Smalltalk terminology or data members in C++ terminology or whatever term is used in your programming language.

Smalltalk directly prohibits access to instance variables at the syntax level. As I mentioned above objects in Smalltalk program can interact only by passing/receiving messages. Many other languages allow access to instance variables at the syntax level but it's considered a bad practice. For example, the famous Effective C++ book contains the corresponding recommendation: Item 22: Declare data members private.

The reasons are:

• syntactic consistency (the only way for clients to access an object is via member functions or message passing);
• more precise control over the accessibility of data members (you can implement no access, read-only access, read-write access, and even write-only access);
• you can later replace the data member without breaking your public interface.

The last one is the most important. It's the essence of encapsulation - information hiding on the class level.

The point about encapsulation is more important than it might initially appear. If you hide your data members from your clients (i.e., encapsulate them), you can ensure that class invariants are always maintained, because only member functions can affect them. Furthermore, you reserve the right to change your implementation decisions later. If you don't hide such decisions, you'll soon find that even if you own the source code to a class, your ability to change anything public is extremely restricted, because too much client code will be broken. Public means unencapsulated, and practically speaking, unencapsulated means unchangeable, especially for classes that are widely used. Yet widely used classes are most in need of encapsulation, because they are the ones that can most benefit from the ability to replace one implementation with a better one.

(с) Scott Meyers, Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)