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

21–30 of 38 posts

Re: Law of Demeter and immutability

#21

Post by vkhorikov »

jessedhillon wrote: post #20
vkhorikov wrote: post #15

Earlier quoted context omitted.

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 ch…

I do agree with this one.

Re: Law of Demeter and immutability

#22

Post by recursive »

lomnakkus wrote: post #17
recursive wrote: post #10

Earlier quoted context omitted.

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)?

The nulls get coalesced. In what way is it not solved?

Re: Law of Demeter and immutability

#24

Post by kazagistar »

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.

In Rust, an `&Thing` (reference to thing), `Option` (optional reference to thing), `Box` (thing on the heap), and `Option>` (optional thing on the heap) all have the same in-memory representation of a single pointer, but prohibit accidentally dereferencing a null pointer, and make non-nullable pointers the default.

Re: Law of Demeter and immutability

#26

Post by Koshkin »

This "law" sounds like a reasonable idea, at first, but if you think about it for a few seconds, you'll realize that it makes little, if any, sense (at least, when taken out of some specific context). As the designer of the class, often neither you can possibly anticipate all the ways in which objects of the classes involved will be used, nor would you want to re-expose all (or some of) the APIs provided by the "subordinate" classes.

Re: Law of Demeter and immutability

#27

Post by paulddraper »

Koshkin wrote: post #26

This "law" sounds like a reasonable idea, at first, but if you think about it for a few seconds, you'll realize that it makes little, if any, sense (at least, when taken out of some specific context). As the designer of the class, often neither you can possibly anticipate all the ways in which objects of the classes involved will be used, nor would you want to re-expose all (or some of) the APIs provided by the "subo…

I've always thought this to.

Some say the law is actually a guideline.

I say it's one extreme of a spectrum, and we would do well to aim for the middle.

Re: Law of Demeter and immutability

#29

Post by coldtea »

Koshkin wrote: post #26

This "law" sounds like a reasonable idea, at first, but if you think about it for a few seconds, you'll realize that it makes little, if any, sense (at least, when taken out of some specific context). As the designer of the class, often neither you can possibly anticipate all the ways in which objects of the classes involved will be used, nor would you want to re-expose all (or some of) the APIs provided by the "subo…

>As the designer of the class, often neither you can possibly anticipate all the ways in which objects of the classes involved will be used

That's why you subclass -- or compose. The subclass can use them in other ways.

The problem with what you say, that you can't "possibly anticipate all the ways in which objects of the classes involved will be used" is that if you let that happen, then you have to forever support the different ways by which they are used -- and you can't change your implementation internally, make it more efficient etc, because different external code uses various internal details of it.

Re: Law of Demeter and immutability

#30

Post by coldtea »

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".

Still not solving all the problems that an accessor does.

Say you suddenly want to change the position to another unit, or change how it uses position (perhaps return a different position on some cases).

With direct access, you can't.

Post reply on HN