General talk about software patterns

[phillip henry <ph1ll1phenry AT yahoo.com>]

If you're advocating large if/else blocks, I think there is a danger that MDP is categorized as an "anti-pattern".

Your PDF must at least point out this grave weakness or else has little claim to scientific credibility (as Ralph Johnson and Doug Schmidt have already pointed out on this mailing list).

Phill

---

From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
To: phillip henry <ph1ll1phenry AT yahoo.com>
Cc: patterns-discussion AT cs.uiuc.edu
Sent: Mon, 7 February, 2011 20:29:34
Subject: Re: Fw: RE: [patterns-discussion] MDP feasibility questions (processMessage)

Phill,

The example was provided within the context of versioning. I hope it is more clear how/why the Messaging Design Pattern (MDP) improves versioning:

"In general, there is no need to change someone else’s code. The need for creating,
maintaining and merging several versions of the code is also minimized or eliminated."

In terms of your questions, they are linked a related subject.  We probably need to look into the messaging API (processMessage) in more detail.

"As regards the claim "about 5000 function API calls (rough estimate number)" being reduced under MDP to "one messaging interface (or a few) that doesn't change", I'm having difficulty seeing this. Does not the one (or few) simply become 5000 if/else statements? How do you get around this?"

1) No. Not exactly. We can keep the 5000 function calls (same names) encapsulated inside the components as internal functions. The main difference is that each component communicates with other components via MDP messaging
(processMessage). Per our discussion, this is a realistic representation. It improves decoupling, encapsulation, scalability, versioning, etc. In reality, the components, the message, and the messaging mechanism are independent and decoupled. The implementation of processMessage will depend on how the incoming information (message) needs to be processed.

2) In regards to your second question (if/case statements), there is no need to get around it.
This is in harmony with reality. Reality, model and implementation go hand in hand.
Components make decisions based on the input messaging. Often this implies if or case
statements.

An analogy may illustrate these points. Currently you are reading this message word by word. Sentence by Sentence.The messages on the computer screen get transferred to your eyes, and eventually get transferred to another component (brain) via messaging. Several messaging mechanisms are involved including light, neural system, visual system, email. Obviously we process information as we read. Actually we are constantly processing information and making decisions (if/case) based on the information (messaging) received. 

It is similar when we read our email/text messages or go through the newspaper. We process the information and make decisions, based on specific pieces of information (headlines, email/text subject, email/text sender,etc). It is also similar when we
hear a voice. We make decisions depending on the input messaging (urgency, person
who is talking, tone of voice, loudness, distance, etc). A similar situation
happens when we approach a traffic light or a traffic sign.

A lot of the information processing is done almost unconsciously. All our senses work
in a similar fashion. We make decisions based on the incoming information (input messaging) This is similar to how processMessage (message) works and processes information. In a sense processMessage tries to mirror  reality. It is also helps explain why MDP components usually require if (or case) to process the input messages and make decisions. Reality, the model, and the implementation go hand in hand:

public interface JtInterface  {

/**
  * Messaging interface used for the implementation
  * of the messaging design pattern.
  * Process a message and return a reply.
  */

  Object processMessage (Object msg); 


}

Process message often needs to make decisions based on pieces of the message
received: message subject, type, Id, etc.
Obviously the processMessage implementation will depend on the functionality being provided.It is not always the case that we need to make a decision (if/case). You may need a component that translates a message from one format to another or add a list of numbers.


In terms of compilation, the latest version of the paper contains a section discussing implementation considerations. The Messaging interface can be restricted to handle specific type of messaging. Syntactic errors will be catched at compilation time:

"public interface MyMessagingInterface {
                   MyOutputType processMessage (MyInputType message); }   

This is also a valid implementation of messaging. Advanced object oriented technologies provide features like Java generics which allow the types to be parameterized:

 public interface MDPInterface<Type, Type1>  {  Type1 processMessage (Type msg);  }"

Our hearing and visual senses are restricted to certain kind of messaging. MDP can mirror this same behavior.

As a point of information, a messaging queue is not needed unless we are dealing with asynchronous messaging and/or multithreading. We haven't discussed this so far. The versioning example only discusses synchronous communication (no message queue required). processMessage (message) is the only API/functionality required.

A message that gets overlooked is very unlikely because of the many software engineering steps that are required: project planning, schedules, development that involves communication between the team, unit testing, integration testing, Acceptance Testing, etc. 
For instance, under the TDD methodology this wouldn't be an issue: the test case for the specific message would fail very early (not later than development/Unit testing).


I hope this helps clarify the versioning example and how the information is processed withing the context of the MDP messaging API.

Regards,

Al