Refactoring for Loose Coupling

Consider a client-server model that looks like the following:

class Client {
    private Server server;
}

In this example, Client interacts directly with Server In other words, they are tightly coupled. It may be better to extract an abstract interface from Server that Client can interact with.

Recall this example from Chapter 4:

public class Client {
    public void bar(D d) {
        E e = d.getE();
        e.doTheThing();
    }
}

bar(d) is tightly coupled to both D and E.

D must produce E, but e.doIt() is still fully contained within bar(d). Recall that this violates the Law of Demeter.

To reduce this coupling, we might remove the intermediate D object as follows:

public class Client {
    public void bar(E e) {
        e.doTheThing();
    }
}

We may also hide the delegate¹ by giving D a method that calls the function from E itself. This means foo is no longer talking to E (the "friend of a friend"), only D.

public class Client {
    public void bar(D d) {
        d.doTheThingOnE();
    }
}

Notice that this creates a middleman structure, which is itself a code smell. That doesn't mean a middleman structure is always a bad idea! A middleman may be used to avoid interclass dependencies or created on purpose (Proxy, Decorator patterns).

Footnotes