LawOfDemeter

Context : OnModularity

https://en.wikipedia.org/wiki/Law_of_Demeter

The Law of Demeter is that you only talk to your friends.

Or, in OO, terms, you don't build up long chains like this

O.doSomething().doSomethingElse().doYetAnotherThing();

OTOH, in other contexts, the UnixPipe or ClojureLanguage threading macro (or I guess some Haskell monads) this pipelining / threading way of thinking is a good thing.

-> X f1 f2 f3

Why the difference?

Why is the Law of Demeter good advice in OO? But the opposite is true for FP?

Well, OO is focused on DataHiding and opaque module boundaries.

So when you do O.m1().m2().m3(), your code needs to know not just that O has an m1, but that the result will be an object that speaks m2, and the result of that will be an object that speaks m3 etc.

You need to know a lot about the innards of the innards of the innards. Which is exactly what you shouldn't.

Instead, in OO, you want to write

O.finalResult();

It's up to O to implement finalResult() in such a way that it uses the innards correctly. And then a later O can change its mind on that.

OTOH, in FP-like pipes,

-> X f1 f2 f3

• a) there will have been less emphasis on black boxes in the first place. f1, f2 & f3 may all be defined within the scope of this particular file / module. So knowing what come out of each is not frowned upon.
• b) ImmutabilityBeatsDataHiding.