"Message Chains" vs "Middle Man"

Question

I'm reading through Fowler's refactoring book and am a bit confused about those two code smells.

"Message Chains" are calls like a.getB().getC().getValue().

"Middle Man" is a method like

class A
{
    object getCValue()
    {
        return b.getCValue();
    }
}

The way I understand the two section is that if you've got "Message Chains" you shorten them by introducing "Middle Men". And If you've got "Middle Men" you turn them into "Message Chains"...

Now obviously there has to be some limitation to this or you'd have a programmer's merry-go-round. At what point should I favor one over the other?

One is coupling the class to unrelated classes, the other is coupling the class to the structure. So in theory my approach would be to check if any given change reduces one kind of coupling more than it increases the other kind of coupling. But is one kind of coupling worse and should be weighed more? I.e. only add one class coupling if you can remove X structural couplings?

Answer 1

Preferring middle men over message chains is also known as the Law of Demeter, which can be summarized as "only talk to your direct dependencies".

One benefit of using middle men instead of message chains is that you have to provide fewer mocks when doing unit testing. Classes become really hard to test when you have to provide mocks not only for their direct dependencies but also their indirect ones.

It also helps with separation of concerns, as code that has an A and wants a C should not have to know that there's a B involved. This helps modularity.

The main argument for message chains is that you don't have to write the boilerplate in the middle, and it might make sense in some cases, but I think the rule of thumb should be to prefer middle men.