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 receiving messages, processing data, and sending messages to other objects and can be viewed as an independent ‘machine’ with a distinct role or responsibility.”

What exactly does the statement mean in code?

class A
{ 
    methodA()
    {

    }
}


class B
{
    methodB()
    {

    }
}


class C
{
    main()
    {
        A a=new A();
        B b=new B();
        a.methodA(); // does this mean msgs passing??
        b.methodB(); // or does this?? I may be completely off-track here..
    }
}

Answer 1

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)