General talk about software patterns

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

Ralph,

I agree with you in regards to the benefits of the messaging design pattern (MDP). I appreciate your comments. There are applications (scalability) that did not cross my mind. The main purpose of the MDP papers is to convey this information and the concepts behind MDP. Obviously the MDP papers served their purpose. Several people including yourself get the idea. It makes me glad. I love it. Messaging is a sound idea. This is a fact.

On the other hand, there may be a better way of communicating the messaging idea. I'd like to hear any specific suggestions/recommendations. This would benefit the discussion. The ideal situation would be finding a good of way of communicating it so everyone gets it right away. I always welcome any cooperative efforts (book, research papers, articles, projects, etc). These should help further the communication process. I also have to acknowledge my shortcomings as a writer.

Therefore there is no problem with MDP "messaging". We agree on this. Based on your email, the problem may related to the messenger and how the message is conveyed/presented so to speak. I believe this problem can be overcome. I don't see it as a major obstacle. (Please no crazy ideas about killing the messenger ;-).  

Perhaps we should talk about presentation since this seems to be an area of contention/difficulty.

Please bear with me for a minute. I'm working based on the following premises for my presentation of MDP:

- Software applications are designed to model the real world.
- Therefore software models should be as close to reality as possible (realistic model) in order to achieve an accurate portrait. The more realistic the model is, the better off your application will be.
- Messaging is part of the real work. Actually it is everywhere.

Conclusion: Therefore messaging must be part of the model in order to achieve a accurate/complete model. BTW, there are other concepts that are also part of reality ( gravity, forces, etc). Obviously You might to include this concepts depending on your application.

This line of thinking is what I'd like to convey as well. Messaging is a sound idea. On the other hand, I believe a "realistic model" is also a sound idea. I'll be happy to discuss the validity of the premises and the conclusion. I should also help the discussion.

Messaging and "realistic model" are associated. Actually we need messaging as part of the model because our model needs to be as realistic as possible. Otherwise we'll have to face shortcomings/complexity (RPCs).  I'll plan to expand on this. I also plan to address the rest of you comments shortly. When given the proper time and thought, people should realize that, similar to messaging, this is not a crazy idea either. Actually it may be quite useful while working on software models and design patterns. For instance you can come up with a complete Distributed Component Model (second MDP paper) if you make the following association: what you are trying to achieve is already there in the real world. You just need to look at how your phone/mail/email systems (based on messaging) operate and mimic it.

 
Best regards,









--- On Tue, 12/14/10, Ralph Johnson <johnson AT cs.uiuc.edu> wrote:

From: Ralph Johnson <johnson AT cs.uiuc.edu>
Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)
To: "Al Boldi" <a1426z AT gawab.com>
Cc: "Messaging Design Pattern" <dsheppard2k AT yahoo.com>, patterns-discussion AT cs.uiuc.edu
Date: Tuesday, December 14, 2010, 10:25 AM

On Sat, Dec 11, 2010 at 9:46 AM, Al Boldi <a1426z AT gawab.com> wrote:

Can the MDP be used to replace the Observer Design Pattern?

The MDP is not a replacement for Observer.  They solve different problems, and can work together (or not).

Suppose you are programming in C++.  The big idea of MDP is to define one interface with one virtual function, which will have a name like handle() or execute(), or processMessage().  It has one argument, a "message", which might be a C++ object, or a string, or maybe an array of integers.  So, you take your beautiful object-oriented design, with a carefully designed set of interfaces, and replace each interface with a single interface with a single operation.  Of course, processMessage turns into something like a case statement, since you have to do something different for each kind of message.

Your natural reaction *should* be "This is crazy!  What a stupid idea!"   But it is not a stupid idea.  There are times that it is a really good idea.  The problem with the pattern descriptions is that it doesn't explain when this is a bad idea and when it is a good idea.

You would never want to use MDP for a small C++ program.  You might use it in a small program written in a non-object-oriented language, where you wanted to implement objects more clearly.  But its main use is in large programs, where you want to make sure that there is loose coupling between subsystems.  

Static typing doesn't scale.   Suppose your system runs on a hundred servers.  It uses hundreds of different interfaces.  Suppose you want to improve one of them by adding a new operation to it.  You don't want to have to reboot all your servers with a new version of your software.  You'd like to be able to add it to one and then gradually change one component after another to use it.   MDP lets you do this.  

MDP makes it easy to run components on different machines.  Or on the same one.  It works for any language, allowing non-OO ones to pretend to be OO.

On the other hand, MDP defeats static type checking.   It does not take advantage of OO features built into  language, so it can be verbose and indirect.  You wouldn't want to do it everywhere, but in the right places, it can be very effective.

>The MDP papers are mainly geared towards the messaging concept based on a realistic model. 

>I tend to place a lot of emphasis on the concept, abstraction and realistic model. In my opinion, 

>concept and interface are the main aspects in order to achieve a successful implementation.

I think your papers are not working.  Most people don't get the idea after reading them.   I think the problem

is that you focus too much on this "realistic model".  The problem is that the realistic model can be

interpreted in many ways, and MDP is only one of them.   Smalltalk programmers ALL use the same model.

When I read your paper for the first time, I thought you were just talking about the classic OO model that

we Smalltalkers have loved for 30 years.  You need to try to write things that cannot be misinterpreted.

I think you are trying to avoid having people say "You are crazy!" right away, but if they properly understand

what you are saying (and they have not seen this pattern used properly before) then they will say it.

They ought to say it.  When people say "You are crazy!" then you know that they are starting to understand.

Your job is to convince them that you are not crazy, that this is in fact often a valuable pattern.

-Ralph Johnson