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