Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Law of Demeter and immutability

enterprisecraftsmanship.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Law of Demeter and immutability

#11

Post by debacle »

lomnakkus wrote: post #6
debacle wrote: post #3

> The law of Demeter is a guideline I'm not really sure that much more had to be said than that. There are many instances (especially when you have a data structure that is also a class) where the law of Demeter is a guideline and just that. However, the caveat is that this: int positionX = player.Position.X; Should really look like this: if(player.Position != null) { int positionX = player.Position.X; } In which cas…

... or you could just use a language which doesn't allow "null".

I can't think of a programming language used for game development that doesn't have null.

Re: Law of Demeter and immutability

#12

Post by lgunsch »

whack wrote: post #5

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, a…

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.

Re: Law of Demeter and immutability

#13

Post by gpderetta »

debacle wrote: post #11
lomnakkus wrote: post #6

Earlier quoted context omitted.

... or you could just use a language which doesn't allow "null".

I can't think of a programming language used for game development that doesn't have null.

C++, unless pointers are explicitly used, which weren't in the OP example.

Re: Law of Demeter and immutability

#14

Post by TickleSteve »

Conlectus wrote: post #8

There is in my mind another important benefit of following the Law of Demeter: it minimizes coupling. Even in functional programming if you are digging into a data structure 5 levels deep, you are potentially coupling a function to 5 different structures, rather than just one. For example: game.player.bbox.topLeft.x has the potential to break if the game, player, bbox, or point structure change, which makes it fragil…

Coupling is what the LoD is about, not mutability, its not just another important benefit, its the main point.

Re: Law of Demeter and immutability

#15

Post by vkhorikov »

whack wrote: post #5

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, a…

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.

Re: Law of Demeter and immutability

#16

Post by douche »

recursive wrote: post #10
lomnakkus wrote: post #6

Earlier quoted context omitted.

... or you could just use a language which doesn't allow "null".

Or use a null safe member access operator like the one in c#. player?.position.x

If it's C#, you could also make Position be a struct that can't be null. Generally things like Points and Vectors are structs anyway in a lot of cases for performance reasons.

Re: Law of Demeter and immutability

#17

Post by lomnakkus »

recursive wrote: post #10
lomnakkus wrote: post #6

Earlier quoted context omitted.

... or you could just use a language which doesn't allow "null".

Or use a null safe member access operator like the one in c#. player?.position.x

That doesn't really solve the problem. What if "x" is a nullable type (i.e. not a primitive type)?

Re: Law of Demeter and immutability

#18

Post by lomnakkus »

debacle wrote: post #11
lomnakkus wrote: post #6

Earlier quoted context omitted.

... or you could just use a language which doesn't allow "null".

I can't think of a programming language used for game development that doesn't have null.

I'm not sure I understand exactly why this is specific to game development? (I see that the article uses a game-like example, but...)

Even so: I'm pretty sure Rust is suitable for game development being essentially zero-overhead, non-GC and Rust effectively disallows "null".

(That, and C++ if you allow only references like another poster mentioned.)

Re: Law of Demeter and immutability

#19

Post by hinkley »

whack wrote: post #5

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, a…

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.

Re: Law of Demeter and immutability

#20

Post by jessedhillon »

vkhorikov wrote: post #15
whack wrote: post #5

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, a…

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.

Post reply on HN