(almost) Always message-oriented is better

The paradigm of object-oriented programming in its maximum expression is the passing of messages between objects.
The OOP is sometimes described with its principles of:
- encapsulation
- inheritance
- polymorphism

However, polymorphism and encapsulation are what make this programming paradigm unique (inheritance is, in addition to something you can achieve in other development models, more of a problem than a value in most cases, due to its abuse and misuse).

Grady Booch defined object–oriented programming as “a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships”.

But despite my admiration for Grady Booch, I prefer this words from Alan Kay (3):

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things” — Dr.Alan Kay

The best designs are born from designs where the elements are decoupled and do not know their counterpart (principle of inversion of control). And to achieve this very important principle of design the classes must follow that(1):

• High-level modules should not depend on low-level modules: both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions

Alyhough these principles are achieved with the use of interfaces they can be obtained in an even better way as Mr. Kay said with messages between objects. In its best, a good design enforces that the sending object only knows the interface (contract) of the object that implements the interface but in a message-oriented design, even that is not known: the only contract is the format of the message being sent.

Spring Application Events

Curiously one of the most interesting features of the Spring framework is one of the great unknown and very little exploited:
the passage of messages within the same context of Spring among the managed beans. (2)
With this facility you can obtain very decoupled designs in a very simple way, and also within the Spring model, without having to implement anything else.
Yes, they are messages within the same JVM, and by default synchronous (the thread is the same in the sending and attention of the message) but they are still very interesting if you do not need to incorporate more powerful models as could be, for example, the actors (which is, in my opinion, the really object oriented approach). (4)

We will explain actors in a future article.

(1) Agile Software Development, Principles, Patterns, and Practices Robert C. Martin, Jan M. Rabaey, Anantha P. Chandrakasan, Borivoje Nikolic

(2) https://spring.io/blog/2015/02/11/better-application-events-in-spring-framework-4-2

(3) http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

(4) https://theory.stanford.edu/~jcm/cs358-96/actors.html