General talk about software patterns

["Douglas C. Schmidt" <schmidt AT dre.vanderbilt.edu>]

Hi folks,

   It strikes me that there's a fundamental disconnect at the heart of
this discussion.  Pattern form is best used to give (among other things)
a dispassionate evaluation of the (often contextually related) pros/cons
of recurring design abstractions.  It's not well suited for advocating
the superiority of one particular design abstraction over all others in
all situations.  Al's goal seems to be to convince everyone that MDP
should be *the* solution to all software design problems, which is
clearly (at least to me) not defensible for all the reasons that have
been mentioned here the past months.  I'm reminded of the old saying "a
zealot is someone who can't change his/her mind and can't change the
subject."  Perhaps it's time to change the subject.

Thanks,

        Doug

> Hi, Al,
> 
> I'm still awaiting a response to my reductio ad absurdum argument and 
> Christian
> Köppe's questions, both of 22 December 2010.
> 
> 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?
> 
> Also, how are you addressing the issue of what Steve McConnell calls 
> "Semantic
> Coupling"?
> 
> "Semantic coupling is dangerous because changing code in the used module can
> break code in the using module in ways that are completely undetectable by 
> the
> compiler. When code like this breaks, it breaks in subtle ways that seem
> unrelated to the change made in the used module, which turns debugging into 
> a
> Sisyphean task."
> Code Complete, Second Edition (p32)
> 
> Although the interface does not change in MDP, the behaviour can and the
> compiler will not catch this. And I'd rather have compilation problems than 
> odd
> behaviour once the code was deployed.
> 
> Phill
> 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Messaging Design Pattern 
> <dsheppard2k AT yahoo.com>
> To: 
> patterns-discussion AT cs.uiuc.edu
> Sent: Wed, 26 January, 2011 2:19:38
> Subject: Re: [patterns-discussion] MDP feasibility questions - Versioning/
> Implementation considerations
> 
> Dear list members,
> 
> I agree that versioning is a realistic problem for many organizations. The
> messaging Design Pattern (MDP) improves versioning. Versioning is breafly
> metioned in the paper (one paragraph - consequences section). It will 
> probably
> require a separate write up (several pages) to explain it in detail.
> 
> An analogy may illustrate versioning. Human speech is constantly evolving. 
> New
> words, acronyms and phrases are being added to the language on a regular 
> basis.
> Human speech, as a messaging mechanism,  is flexible enough to allow this. 
> For
> instance
> think about the word "smartphone"  (a few years old - the email software  
> flags
> it as misspelled). In a sense we are using "new" version of the language
> (upgrading the language).The language is able to evolve. This is another
> quality/property of messaging. It
> provides for smooth versioning. This works provided that we do it in a 
> backward
> compatible
> way (syntax/semantics of old words and phrases remain unchanged although 
> some
> may
> become obsolete with time). The language evolves becoming more complex
> because of the new information being handled. I can imagine the time where 
> the
> language
> was very simple and consisted of a few words. Children start with a single 
> word
> in their vocabulary.
>  
> In terms of versioning, components that use MDP messaging behave in a 
> similar
> fashion. You can add new messages to the communication between components.
> Traditional O-O technologies that don't rely on messaging present complexity
> and limitations. Adding a new parameter to a function, and the software 
> won't
> compile. If you have a library of components, you will need to use the 
> matching
> version of the component library. Otherwise your software won't compile. You
> need to keep and maintain several versions of the code. Usually each 
> engineer
> needs to keep a complete version of the whole software tree. Changes to the
> code need to be merged. Coupling between components becomes an obstacle 
> here.
> Both components need to match, in terms of API,  for the software to 
> compile.
> 
> In general, under MDP you only need to keep the latest version of the 
> component
> library as long as the messaging is backward compatible We also need to 
> keep 
> in mind the complexity of the problem. Let's say that we have 1000 
> components.
> Let's say that each component need to makes 5 distint calls to external
> components. We are talking about about 5000 function API calls (rough 
> estimate
> number). Under MDP you have one messaging interface (or a few) that doesn't
> change. You can compile and run against the latest version of the MDP 
> component
> library. In general, new version of the library doesn't break compilation/
> running version. This can also give you an idea of simplicity. It is one
> messaging primitive versus 5000 API calls (very rough estimate). Any 
> changes/
> versions and the program will not compile under the traditional O-O 
> approach.
> It becomes a complex problem to manage. If we are using RPCs it becomes even
> more complicated.
>  
> Ideally you can also divide the work so that only one person is responsible 
> for
> a MDP component. This minimizes or avoids merging. The components only need 
> to
> agree on the syntax/semantic of the messaging being exchanged. In general 
> old
> code is compatible with new versions of the MDP component(s):
> 
> "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."
> 
> We can say that our language is becoming more complex on a regular basis. 
> This
> is probably accurate. It needs to be that way because we are dealing with 
> more
> information (new words, phrases, etc). I don't believe we can get around 
> this
> additional complexity. Complexity increases because we need to handle more
> information. On the other hand, messaging is simpler than the traditional
> approach.
> 
> Notice that when we are listening, we are processing information. We are 
> also
> making decisions based on the information received (message subject/topic, 
> tone
> of the voice, sender, etc.)
> 
> Arguably, not much different from MDP components that behave like a state
> machine and process information (messages) making decisions based on the
> messaging received:
> 
> processMessage (message) // MDP messaging interface
> 
> 
> I hope I was able to answer the questions/comments posted so far. Please 
> let me
> know if I overlooked anything since I received a fair amount of comments and
> question. Feel free to send me email or post to list if there is anything 
> that
> needs further clarification.  
> 
> Regards
> 
> Al
> 
> 
> 
> _______________________________________________
> patterns-discussion mailing list
> patterns-discussion AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion