Comment by whack | Hacker News Reader

Comment by whack | Hacker News Reader

The author claims that Dementer's law is primarily there in order to prevent state corruption. I don't know if I agree with this premise. There are also 2 other reasons to follow Dementer's law:

1. Make it easier for your users to achieve specific goals through a single method call, instead of having to know & go through a chain of method calls. Ie, instead of having to know that the Dog object has Leg sub-objects, and having to call Dog.getLeg().selectMuscle().contract(), the user can instead just invoke Dog.move(). This enhances simplicity, and makes life easy for your users.

2. Hiding implementation details from your users, in order to maintain flexibility for future changes. If all your users are calling Dog.getLeg().selectMuscle().contract(), then you're forced to work with this Dog->Leg->Muscle implementation. On the other hand, if your users are simply calling Dog.move(), then you're free to refactor the class internal structure in dramatic ways.

The fact that an object is immutable, has little impact on the 2 benefits given above. Dementer's Law/Guideline would be well worth paying attention to for those reasons, even when dealing with ImmutableObjects.

Exactly, the law of Demeter is about coupling... not state corruption and immutability.

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

Whether those are mutable or immutable is irrelevant to the LoD.

There are two other aspects of Demeter that are more about how humans work and where they make mistakes.

One is that merges are hard (error prone), and mixing concerns results in many more merge conflicts. I 'joke' that half of the tenets of clean code are really about avoiding merge conflicts, but I'm quite serious.

Add to this that Demeter means that you can use local reasoning in many situations, which complements the structure of human working memory. I cannot juggle twelve facts when debugging issues, and Demeter helps you push potentially confounding issues elsewhere where they cannot distract from the matter at hand.

Coupling is an important concept but I think this concern can be mitigated by following the DRY principle. That is, if you have only one function that knows about the object’s internal structure (“couples” to it, so to speak), it doesn’t really matter where exactly that function is located – in the class itself or in some other place.

Also, your example isn't entirely valid as you mutate the objects' state.

Demeter's Law is also called the Principle of Least Knowledge. The reason being that, if you have two dogs -- one robotic and one mammalian -- reading the angle of the second joint distal from the hip is going to walk a distinct path for each type, which requires some otherwise-dog-agnostic piece of code to now know about what types of dogs exist and how to traverse their skeletal chains.

IMO Law of Demeter is not chiefly about state protection -- it's a principle of good design which, when followed, unburdens developers from the cognitive load of keeping the entire universe in their heads. It forces them to think about what is the smallest amount of information this component needs in order to function.

I do agree with this one.

It seems like you're trying to redefine what the LoD is because you think there's a more important principle it should refer to instead, or because you disagree with its original framing. That's not going to be a fruitful approach.

I came here to say exactly this. Those two benefits far outweigh state corruption. The law of Demeter is a good guide to a better API, which ends up being more effective.

Reply on news.ycombinator.com