Dear anonymous,
I feel that we're going around in circles here. I agree with Christian Köppe
that we need hard examples of why this pattern is useful.
I still see it as nothing more than:
public Object doSomething(Object object) { ... }
How does this help me write better code? If anything, as another contributor
pointed out, this encourages switch statements in the method block - something
of an anti-pattern...
By the way, I'd remove comments like "based on observation and faith we can
believe that there is great Designer". I don't think this is a forum for
religion.
Phill
________________________________
From: Messaging Design Pattern <[email protected]>
To: Ralph Johnson <[email protected]>
Cc: [email protected]
Sent: Wed, 22 December, 2010 2:27:23
Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging
Design Patterns (MDP) reusability and QA)
Ralph,
I hope I've been able to convey why I think the idea of a realistic model can
be useful while modeling software. I think it is something to think about. As I
said earlier, it can prove to be quite useful given the proper consideration.
It
can give us a framework to think about problems and their solutions. It can
help us explain concepts. We can extract solutions from reality. Obviously the
model and the reality being represented should go hand in hand. Specifically
it
helps illustrate why traditional technologies including O-O and distributed
component technologies need to add messaging in order to achieve a more
complete/accurate model.
You raise a valid point regarding trade-offs. We can ask ourselves, why is it
apparently difficult to find problems/trade-offs with messaging ? A very simple
concept and yet it has wide applicability. Components are everywhere. So is
messaging. Messaging "is". Similar to Gravity and other natural laws, all
these
concepts exist in the real world. I'm not sure we can think of objects, gravity
or messaging in terms of trade-offs. In this sense, the messaging concept
doesn't seem to behave like other Design patterns where design trade-offs need
to be made. Messaging is similar to the concept/abstraction of objects, force
and gravity. In the case of messaging, it has been developed and improved for a
long period of time. These communication mechanisms have gone through a process
of natural selection. In the case of messaging between people (human speech),
it
is highly effective and efficient.
I'm afraid I cannot give you a better answer based on facts for this particular
question.
We may ask the same question for other concepts like Gravity and Force.
On the other hand, based on observation and faith we can believe that there is
great Designer behind nature and all things in reality. Perfection is not
unattainable. Gravity and Messaging have been put in place. We can only
attempt
to understand, model and mimic them. Probably we will never be able to find
flaws or improve upon them.
"We can gain valuable insight from the patterns found in nature and the real
world regarding the inner workings of specific problems and proven alternatives
of solution. Based on our observation of the world around us, we need to think
in terms of a messaging paradigm while designing and building distributed
applications. Software engineering processes are improved as a result. We need
to think not only about self-contained components but also in terms of the
information (i.e. messaging) being exchanged between these components. In
reality, these two aspects are independent and separate from one another. In
our particular scenario, we have been able to employ the messaging paradigm to
define a complete distributed component and messaging model in which
transparent, secure and reliable communication between components/applications
is accomplished. As always, we should praise the wisdom of the Designer for the
versatility and simplicity of nature’s patterns and beautiful design."
I'll cover implementation aspects shortly. Also, I'll update the MDP paper
based
on the comments/questions received. Specifically in the areas where additional
clarification is needed to avoid misinterpretations.
Blessed holidays for all of us.
--- On Wed, 12/15/10, Messaging Design Pattern <[email protected]> wrote:
>From: Messaging Design Pattern <[email protected]>
>Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging
>Design Patterns (MDP) reusability and QA)
>To: "Ralph Johnson" <[email protected]>
>Cc: "Al Boldi" <[email protected]>, [email protected]
>Date: Wednesday, December 15, 2010, 3:17 AM
>
>
>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 want to include these
>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,
>
>
>
>
>
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
