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
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
