An Overview of Message Passing in Object-Oriented Programming

Object-oriented programming as a programming paradigm is based on objects. Objects are a representation of real-world and objects communicate with each other via messages.

When two or more objects communicate with each other that means that those objects are sending and receiving messages. This is often called method calling.

Sending object (Object A) knows which method of receiving object (Object B) is being called, so it knows more details than needed. With this, we create code which is not loosely coupled. Changes in one object will lead to changes in others too.

The focus of this blog post will be on the idea of how to create abstraction with focusing on the message sent and how the receiving object decides which implementation to provide according to the message.

This could be done in run time, so the calling object does not need to know which function will be called and what the implementation details are.

The difference between method call and message passing

Technically, there is no real difference between method calling and message passing. But with the term “message passing” authors of this idea are trying to explain that focusing on the message can lead to creating better abstracting then just focusing on objects.

What message passing really is

In computer science, message passing is a technique for invoking behaviour (i.e., running a program) on a computer. The invoking of a program sends a message to a process (which may be an actor or object) and relies on the process and the supporting infrastructure to select and invoke the actual code to run. Message passing differs from conventional programming where a process, subroutine, or function is directly invoked by name.

Messaging design patterns

Messaging design patterns allow components and applications to exchange information. Through separating component interaction from component functionality, it facilitates decoupling, encapsulation and reusability.

The motivation of introducing them is creating the intermediary layer that transfers the message from sender to receiver. The sender and the recipient don’t need to think about how the message is transferred, it is the responsibility of the messenger.

Messaging design pattern is used to implement or help implement other well-known design patterns like Gang of Four design patterns.

One of the patterns that explain how the communication between objects could be implemented is the Strategy pattern.

Strategy pattern

The strategy pattern (also known as the rule pattern) is a pattern in behavioural software design that enables an algorithm to be selected at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions to which in a family of algorithms to use.

The main point of this blog post is to show how Object A and Object B need to know about each other. The algorithm will be chosen in run time.

With strategy pattern we can hide the details of algorithm implementation, so the use of a different strategy will perform the same functionality of object differently.

The example will be written in C# code but if you are familiar with any other object-oriented language you will not have a problem understanding the big idea.

Example of Strategy pattern

On Picture 1 we can see the UML class diagram of Strategy pattern and a basic example.

Real-life example (as mentioned before written in C#) is showed in picture 2.

Let’s assume that we have ITCompany who is looking for new employees. There are several ways that a company can do this. For example, a company can post a job add on career search website, a potential employer can apply for the job via internal websites, LinkedIn pages or some other social media site.

Or the company can choose some head hunt agency for these purposes. Let’s observe IHeadHuntAgency as a middle layer that will provide an employee to the company.

That middle layer will choose a strategy for finding an employee. Message sender (IT company) and receiver (a concrete tool for finding an employee) will not know about each other.

The ITCompany class does not need to know detail implementations of concrete job search possibilities. Company will know only about interface IHeadHuntAgency.

The idea of message passing is “sending object will just send a message to one object and the other object will decide what to do”.

So if the new option for job applying is being provided by the agency in the future, it will easily be added without any modifications of ITCompany class and other existing concrete implementations.

Conclusion

Better focus on messages improves decoupling, encapsulation and reusability by separating component communication from component functionality. We at PanonIT are focused on creating software that is decoupled, easy to maintain and adaptive to changes.