4

I want to implement loose coupling in a project.

I know two examples of successful loose coupling designs:

  1. On a Unix workstation, shell scripts realise a loose coupling between basic utilities. The loose coupling relies on the shell's ability to blindly redirect data flows between utilities, without having any knowledge on the structure. Utilities agree on a common form to cooperate like a pipe-separated format for sort, cut, paste, awk, etc., a svn dump or a trivial dump of a normalised SGML document (with onsglmls).

  2. On a Mac OS X system, Applescripts can be regarded as a loose coupling.

In these two examples, I see that cooperating components agree on a common protocol to serialise and deserialise data that needs to be exchanged. Thus components depend on the serialisation protocol rather than on internal representation of data.

Is the implementation of a stable communication protocol between application components a winning strategy to implement loose coupling (and good encapsulation)?

To solve ties, I also ask what would be a nice name for the protocol artefacts: “data” is a bit vague and there is a lot of them at various places in a software!

2
  • Your "data" could be an "object". And your "loose coupling" could be "polymorphism". I think my terms, though, are meant for use deep inside an OO language, where you're talking more at the OS level. Nov 21, 2013 at 14:43
  • 1
    Asking how to implement "loose coupling" is a bit like asking how to implement "fast". Loose coupling isn't a "thing", it's a way to describe a system. Nov 21, 2013 at 22:09

2 Answers 2

9

First of all, it isn't correct to say "implement loose coupling". Loose coupling is a design principle, and a principle can be applied but not implemented. That being said, you can apply that principle to any project you like.

Regarding the examples, IMO they're samples of design by contract. The components agree upon an interface or protocol through which they can interact. While the components may change their internal structure or logic, the interface of interaction remains the same.

It is fair to say that design by contract is a sample of applying loose coupling. But the implication of loose coupling isn't limited to design by contract only. It can be applied to any project to keep the pieces as independent as possible.

I think you might be interested in measuring coupling and cohesion and Demeter's law and it's relation to coupling.

2
  • 1
    Thank you for your answer, references are useful! I think however, there is something more than design by contract in the examples. For instance in a shell script, utilities agree to work on tabular data presented in some form. It is a very interesting feature of the shell, that it possible to express a workflow without knowing anything about the presentation of data.
    – user40989
    Nov 22, 2013 at 9:01
  • 1
    While examples given my Matt are useful, I value context and references you provided.
    – user40989
    Nov 29, 2013 at 12:26
2

By parameterizing.

For example, here f is hard-linked to lots of other modules:

def f():
    return module1.g(module2.x, module3.y)

Here's a less coupled, but similar, example:

def f(x, y):
    return module1.g(x, y)

And a yet less coupled example:

def f(g, x, y):
    return g(x, y)

Coupling can also occur through types:

String id(String input) {
    return input;
}

So why not parameterize those as well?

<T> T id(T t) {
    return t;
}

The concept of common interfaces goes hand-in-hand with parameterization -- you can't parameterize something without some idea of its interface.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.