Law of Demeter and immutability
enterprisecraftsmanship.com
Law of Demeter and immutability
1–10 of 38 posts
Re: Law of Demeter and immutability
#2Disagree with the premise. The purpose of Demeter isn't to prevent one class from mucking up the internal state of another, that's a side-effect. Its purpose is to prevent one class from being coupled to the internal structure of another so that if you change one, you don't have to change the other. It stops code updates, not state updates, from rippling out.
This is why the original formulation of the LoD didn't talk about instances, it talked about classes. You were only allowed to know about the surface-level structure of your neighbours, but anything else of the same class as your neighbours was fair game. So in the `player.Position.X` example, we actually don't have enough information to know if it's a violation or not: we don't know what class `player.Position` is, and we don't know whether it's a legitimate neighbour class. If there's another `Position` field somewhere in scope that's legit, `player.Position.X` is allowed, because we're already coupled to that structure, and getting to it via the `player` object doesn't add any coupling that wasn't there already.
Re: Law of Demeter and immutability
#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;
if(player.Position != null) {
int positionX = player.Position.X;
}
Re: Law of Demeter and immutability
#4> 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…
[deleted]
Re: Law of Demeter and immutability
#5The 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.
Re: Law of Demeter and immutability
#6> 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".
Re: Law of Demeter and immutability
#7Gross mutable OO null-defensive nonsense.
Re: Law of Demeter and immutability
#8There 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 fragile. If using an IP language with inheritance, it could also break if any of their super classes change.
Re: Law of Demeter and immutability
#9The 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…
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.
Re: Law of Demeter and immutability
#10> 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".
Or use a null safe member access operator like the one in c#.
player?.position.x