Summary
Idiomatic java isn't a place to get inspiration on how to build loosely coupled architectures. Even though Java idioms are extremely useful, when you get to "programming in the large" it's a whole different ballgame.
Advertisement
Bill de hÓra has a very good blog entry "Foundations for component and service models". Bill points to an extremely instructive article from OTI (i.e. the makers of Eclipse) about Evolving Java-based APIs. Bill is dead on right when he says that idiomatic java isn't a place to get inspiration on how to build loosely coupled architectures. That seems to jive very well with my thoughts on loosely coupled architectures. Java idioms are extremely useful, but when you get to "programming in the large" it becomes a whole different ballgame.
Bill has a couple of very interesting recommendations:
Avoid changing or extending the interface methods.
Control change by using a dictionary interface.
Calls should return documents not objects.
Avoid binary compatability.
Don't confuse an API with a contract.
Version the contract.
Don't build an API for data transfer.
Again, its instructive to look at my "Loose Coupling" table to make some comparisons with the list above. Bill's first recommendation appeals to a REST style. This recommendation favors the REST style of using a fixed set of verbs (see "Interface" in table). The 2nd recommendation is the use of dynamic typing (see "Typing" in table). The 3rd recommendation is appeals to coarser grained message passing (see "Messaging" in table). The 4th recommendation is the concept of leveraging a lingua franca .
Now, recommendation 5,6 and 7 are all quite unique. The 5th recommendation says that there's more to interaction that just the API's, rather we should all consider contracts. This of course has been hinted on by all those Web Services choreography initiatives. Being able to introspect the definition of how parties interact is something completely absent in conventional programming. The 6th recommendation is extremely interesting and I would like to see how he goes about doing this. Finally, the 7th recommendation is an appeal to be pragmatic.
With these new recommendations, I think its time to update my original "Loose Coupling" table:
However, I have seen several examples of systems whose internals attempt to remain as loosely coupled as the interfaces they present externally. They fail to separate the internal private core from public API/services.
For example, the internal (private) system working directly on the XML documents instead of working with objects models (assuming OO) - very, very slow, difficult to work with and a nightmare to maintain.
I believe that the idioms of your chosen language are good for the internal private system components but the external interfaces should be as you have described.
I notice you call the table the "Loose Coupling table", but then describe the aspects of loose and tight coupling. I might conclude that you are implying that loose coupling is better than tight coupling.
Loose coupling tends to work by adding a layer of indirection or abstraction. It seems that few people think about the disadvantages of loose coupling and only focus on its advantages. When loose coupling is abused or misapplied, you have unneeded indirection and abstractions, requiring extra setup, inefficiency, extra complexity, and translations between concepts.
Don't get me wrong, as a designer and developer I'm focusing most on internalizing the concepts of coupling and ramifications from it. I feel it's the most important structural aspect of design, and despite the relative simplicity of its basic concepts one of the least well understood.
I do not think loose coupling is the universal truth, however. I think that coupling should be managed, and smart decisions made about it. I do think your table goes a long way to stating the tradeoffs.
My argument is that for "programming in the small" choose a system like Java, however when you start scaling up to much coarser components, begin to employ a dynamic approach.
Yes, the move to more indirection is just in line with the history of computer science, where almost every language innovation has meant more indirection. However, everything requires balance, knowing when and where to apply indirection is a skill one needs to master.
Previous Topic
