General talk about software patterns

[Messaging Design Pattern <dsheppard2k AT yahoo.com>]

Ralph,

I've updated the design pattern to address your comments. The updated version can be found at http://freedom.lunarpages.com/pattern/messaging.htm. There are some tradeoffs to consider as you suggest in your earlier message:

- In order to take full advantage of this design pattern, people need to think in terms of messaging when they model, design and build software applications: independent entities (i.e. components)
interchanging messages among each other.  This may require learning time and training. Although a messaging approach is natural, intuitive, and consistent with the real world, traditional approaches are based on libraries and method/procedure invocation (both local and remote).

- Transferring messages between components introduces a small overhead when compared with traditional method/procedure invocation. As computers become faster and faster this becomes a non-issue. Also, the benefits of messaging outweigh this small performance cost.  

- The messaging design pattern encourages a disciplined approach that may have a small impact on the initial development time of a component. Messaging should be the only channel of communication between components. External class methods may still be invoked using the traditional approach.  On the other hand, this should be used sparingly in order to minimize coupling and maximize encapsulation. An ideal component is a self-contained unit that interacts with the other components only via messaging. The additional development time is again outweighed by the benefits introduced by messaging. Moreover individual components based on messaging can be purchased or extracted from other applications.

Our basic premise is that the real world works based on a messaging paradigm. It is everywhere. Therefore every program can be modeled, designed and written based on a messaging approach. It is true that you can use the messaging interface everywhere. JtInterface happens to be one implementation of messaging.

In terms of the name, I agree with you. Actually we have struggled while trying to find a suitable/unique name. You or someone else may have a better name for this design pattern. We'll be happy to change it.

I believe this design pattern is about communication, interaction, messaging, information exchange, etc. These are some of the main concepts that come to mind. On the hand, it impacts all the other areas that you mentioned: parallel programming, sync/async communication, coupling, software architecture, etc.

"Lego" architecture is the name that we often use for the architecture that results from using this design pattern (interchangeable components connected via messaging) . Perhaps the "Lego" design pattern could be an alias.

We appreciate your comments. Feel free to send any follow-up comments that you may have.

Best regards,

Ed
http://freedom.lunarpages.com/pattern/messaging.htm



--- On Thu, 2/25/10, Ralph Johnson <johnson AT cs.uiuc.edu> wrote:

From: Ralph Johnson <johnson AT cs.uiuc.edu>
Subject: Re: [patterns-discussion] Messaging Design Pattern
To: "Messaging Design Pattern" <dsheppard2k AT yahoo.com>
Cc: patterns-discussion AT cs.uiuc.edu
Date: Thursday, February 25, 2010, 11:30 AM

Every single consequence in the pattern was positive.  In other words, you only say good things about the pattern, nothing bad.  if this were true, you'd use it in every program.  Don't use any other interface except JtInterface!  Use it everywhere!

This is a common problem with patterns.  The pattern writer is so enamored with his pattern that he only wants to say good things about it.  But design is about tradeoffs.  There is a cloud with every silver lining.    If you don't understand the costs of a pattern then you don't understand the whole pattern.  And if you don't describe the costs then you sound like a used-car salesman.

I've heard this called many things.  I don't like any of those names because they can be interpreted in many ways.  i don't like Messaging, either.  Perhaps it is about parallel programming, and the pattern is to avoid shared memory and communicate only by sending messages.  Perhaps it is about distributed systems, and explores the difference between synchronous and asynchronous communication.  No, this pattern is about software architecture, and is about how to keep loose coupling between modules.  Pick a name that can't be misinterpreted.

-Ralph Johnson