A false claim about loose coupling

Sometimes when loose coupling between modules is described as a desirable property (which it is of course), an somewhat exaggerated claim is made about its benefits. See for example the section "The Benefits" in OSGi – The Business Drivers:
As long as the module boundaries don’t change, one can change the functionality of the module freely, without concern for breaking the wider system; i.e. the impact of any local change is prevented from leaking into the wider system.
When the implementation of a module is changed without changing its interface, the only certainty that you have is that it can be invoked just like its previous implementation, without recompilation. But above that, nothing is certain. My point is that a module is invoked for a reason: to perform some useful work. The interface of a module says something about the structure of the information that it needs to do its work, but very little about the work that it will do, and very little about how the information provided to it will be used to influence the work done.

Take for example a module that offers a service to transfer money from a checking account to a saving acount. Its interface will probably specify the account numbers of the accounts involved and the amount of money and the currency as required parameters. What if a new implementation, instead of faithfully depositing the exact same amount to the saving account that it withdraws from the checking account, now does nothing at all? Or worse, deposits just a little less that the amount withdrawn? Or performs the transfer of money in the reverse direction? Does this not break the 'wider system'? Of course it does!

Coupling may be more subtle than just whether or not it breaks compilation. Testing the new configuration is still needed, automated (preferably) or manual. And testing is usually still an order of magnitude more expensive than compilation.


Richard Nicholson said...


Your Payments example certainly would break the larger system. However the point isn't that modularity stops this from happening rather:

1) It is easy to unit test the "Service Transfer" module and detect that it is indeed broken.

2) The whole system can be rapidly re-wired with a new "Service Transfer" module that actually works.

Point which are made in other parts of my blog. Therefore I think the claim remains quite valid.

Best Wishes


Eric Jan Malotaux said...

You are right of course, but only if you are responsible for both the larger system and the module in question, and if you are the one writing the unit tests for it along with implementing its functionality.

But if the module is someone else's responsibility, the unit tests are also out of your control and could be changed to accept any other functionality.

I failed to mention in my original post that I was also thinking about the same claim being made in the description of Loose Coupling as one of the SOA principles in http://www.soaprinciples.com/service_loose_coupling.php. In de SOA world it is considered normal to compose an application from services from different domains under different responsibilities.

I still don't know of any way to formally specify the functionality that you expect from another module as exactly as you can specify its interface.

Bello said...

It all depends on how you define the definition of "interface".

If one defines an interface as the shape of a message/request/response (e.g. wsdl) than, yes it is true that changing the implementation might break the system.

If one defined an interface as the combination of the shape AND it's behaviour (e.g. if a message that is shaped in a certain way is sent, funds will be tranferred to a savings account) than way the funds will be transferred can be changed feely, because this is just implementation. (The how) But if e.g. funds are not transferred to a savings account, but an other action is taken (or another action is added) (The what) than the interface will be broken.
It is evidently that breaking the interface, breaks the system.