Message Oriented Programming

Message Oriented software systems exist -- ServiceOrientedArchitecture, and so, but they don't generally correspond to a language paradigm, because they are generally written in multiple languages. Message Oriented Languages are rare to non-existent If you did have a language that actually worked that way, not just as a metaphor, you might have something sufficiently based on MessageOrientedProgramming to please AlanKay.

What is the difference between a message send and a method call? The first is dynamic, the second static. Various things stem from that. Message receivers can for instance choose to ignore messages, relay them, or handle them in different ways. The message is in effect, a request, not a command. MOP is a departure from strictly imperative programing.

SmalltalkLanguage uses DynamicDispatch, so it is message orientated..but not enough to satisfy AlanKay. What more is needed? Its messages are not first class citizens, separable form message sends, they cannot be composed piece-by-piece and their syntax is limited. (A class interface wants to be a language).

A distributed system consisting of clients accessing a StructuredQueryLanguage database does not have any of those limitations. SQL is a rich language, maybe even too rich. SQL requests are often built up in several stages by clients. The system is truly message-orientated, but a language it is not.

You have an ObjectOriented software system. A few objects are involved in a given message (a.k.a. method call). Which object should handle the message?

The MessageOrientedProgramming answer is "None."

	:	This link is dead.

At first, this looks like regression to structured programming, or putting all the behavior into one big "actor" class, leaving all the other classes as data bags.

Upon further inspection, it's reminiscent of double-dispatch, and patterns like Visitor, where a couple of classes negotiate to find the behavior that responds to the message.

Then it looks like the Facade pattern, with a broker providing a facade to all the classes in the system under discussion.

Finally, it triggers the memory of that AlanKayOnMessaging quote where he talks about regretting the term "Object-Oriented Programming", specifically the "object" part, since now people are focused on the objects themselves, instead of on the space between them (their interactions).

Is there a real problem here that MessageOrientedProgramming is solving? Or is it just people forgetting to shield themselves with Facades in the appropriate places?

Can we hijack the term to mean, "ObjectOriented, only quit looking at the objects already" ?

Very few object-oriented applications are "pure" object orientation. Eventually, resuability and independence breaks down at the very top: the application designer creates a main form, where all the Buttons and ListBox? objects become heavily coupled, and start referencing each other.

MessageOrientedProgramming could be an example of that habit of the Main Form, but burrowing a little deeper than the surface; you create a series of objects in your application that all have a 'myMainForm' field in them, and an event in one of the form's sub-objects needs to let the other objects in the form know of it.

MessageOrientedProgramming could be considered a slightly less disciplined form of ObjectOrientedProgramming, and might be the same thing as the Mediator pattern.

How does this relate to EventDrivenProgramming?

EditText of this page (last edited November 20, 2013) or FindPage with title or text search