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!

user40989
  • 2,940

2 Answers2

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.

Community
  • 1
superM
  • 7,373
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.