Timeline for Law of Demeter and over-wide interfaces
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 18, 2021 at 10:38 | comment | added | Flater | @Laiv: You can definitely argue that interpretation, but my answer explicitly mentions that calling it a LOD violation is based on the inference that a dog leg is not considered part of the Dog contract. It assumes a contract like interface IDog { void Move(); } where it only stipulates that a dog can move. How that dog moves is a private implementation detail. Whether it uses legs, hoverjets, or wind sails is irrelevant as far as the contract is concerned. But I agree that OP left the contract up to inference, cfr my comment to RobertBrautigam (13 comments up from here). | |
| Feb 18, 2021 at 10:36 | comment | added | Laiv | Anyways, I agreed, Principles and "laws" should be read and interpreted carefully and applied in the way that best meets your needs. Even break'em occasionally if need it. | |
| Feb 18, 2021 at 10:34 | comment | added | Laiv | By this reasoning (the contract interpretation) I could argue that DogLeg is expected to be part of the Dog public contract and hence not breaking LoD either. If yo leave it open to interpretation then LoD is useless. If you want to narrow down the coupling of certain elements you need to set a sort of rules of thumb. Rules you can break when is convenient. The account example could be one of these convenient cases. But it doesn't mean you are not breaking LoD because you are inherently inheriting the issues LoD is trying to prevent. This is not good nor bad. But it's what it's. | |
| Feb 18, 2021 at 10:28 | comment | added | Flater | @Laiv: People always tersely summarize LOD as "don't talk to strangers", but I'd argue that it's more a matter of "don't handle others' privates, even if they've exposed them". But that's maybe a less SFW interpretation. | |
| Feb 18, 2021 at 10:21 | comment | added | Flater | @Laiv: The "inherently" ends based on how the contracts have been stipulated. LOD at its very core aims to disallow directly handling private implementation details, and instead tells you to only use the contract as it has been specified (and, by extension, to develop your classes so that their private implementation details don't leak and you adhere to their contract). | |
| Feb 18, 2021 at 10:20 | comment | added | Laiv | @Flater then the consumer is inherently expected to know about the interface of User and so on. LoD sets the limits where this inherently should end. | |
| Feb 18, 2021 at 10:20 | comment | added | Flater | @Laiv: If the Account contract stipulated that it contains a reference to a User, then this is not an LOD violation. This means that the consumer who calls account.getUser() is inherently expected to be able to work with a User object, since the Account class contract isn't set up to do it for them. There is a difference between "an account contains its owner's name (and storing that name in a User is an implementation detail" and "an account contains a reference to its owner (i.e. User)". In the former, account.getUser().fullname() is an LOD violation, in the latter it is not. | |
| Feb 18, 2021 at 10:18 | comment | added | Laiv | account.getUser().getName() will cause the troubles LoD tries to prevent you from if user changes and that's not a matter of perspective. It will turn into red all the classes coupled to user, whether you belive user must be accessible for everybody any place or not. If you need access to the user then pass the user not the account. How and who retrieves user from account is a different matter. | |
| Feb 18, 2021 at 8:12 | comment | added | Robert Bräutigam | @user949300 Hehe, "dogmatic" :) I see what you did there :) | |
| Feb 18, 2021 at 7:36 | comment | added | user949300 | This is a great answer and illustrates why dogmatic adherence to the LoD is generally misguided. | |
| Feb 18, 2021 at 6:20 | comment | added | CaTs | @Flater the law of demeter is not subjective, you simply choose whether or not it is worth fixing. | |
| Feb 17, 2021 at 16:49 | comment | added | Christophe | @Flater by I like this idea of telling the objective and let the class carry it out without worrying for implementation details: dog.goto(master) seems simpler than telling the route. I didn’t elaborate on dog in my own answer because there’s no LoD issue (if a class knows about dog, we can assume it can use its public interface; we can argue about granularity of interface but this is not LoD relevant in this case imho) | |
| Feb 17, 2021 at 13:39 | comment | added | Flater | @RobertBräutigam: Just to finish that thought, based on the presented example code, it's in my opinion reasonable to infer that a dog's legs are an implementation detail and the Dog contract only stipulates movement; whereas the Account contract likely stipulates that it has an owner (represented by a User, whose contract in turn stipulates that users have a last name) and not that the account contains its owner's last name specifically. I cannot guarantee that this is correct, but this is why it's called an inference. | |
| Feb 17, 2021 at 13:28 | comment | added | Flater | @RobertBräutigam: It seems you misunderstood my answer. The implicit expectation of the reader of the example code does matter, because we (as the reader) have to infer what the intended contract of the Dog and Account classes is. Example code in questions is usually light on rigorous analysis documentation that would shed light on the things that we are now left to infer. So whether or not we designate this example code as a LOD violation or not, hinges on our implicit inference on what is the contract and what is a private implementation detail. | |
| Feb 17, 2021 at 13:01 | comment | added | Robert Bräutigam | I've made a factual observation about your comment. Whether something is or is not a LoD violation does not depend on the "reader's implicit expectation" as you've tried to argue. That's it. Am I wrong? For reference, here's the original paper. | |
| Feb 17, 2021 at 12:05 | comment | added | Flater | @RobertBräutigam "Calling methods on instance variables of other objects is not allowed." The Law of Demeter is not a dot counting exercise. You cannot and should not judge LOD violations based on the accessing code itself. The surrounding context matters in making the accessing code applicable or non-applicable to LOD considerations. | |
| Feb 17, 2021 at 11:59 | comment | added | Jacob is on Codidact | @RobertBräutigam the law is clear, but it's a rule of thumb, not an actual law. The question isn't "what does the law say?", but "should I listen to the law in this case?". It should make you ask questions like this, not automatically refactor every line with two or more dots. | |
| Feb 17, 2021 at 11:15 | comment | added | Robert Bräutigam | The meaning of LoD in this regard is not really up for debate, it is quite clearly written. Calling methods on instance variables of other objects is not allowed. It doesn't matter what the user of the code or the writer expects. | |
| Feb 17, 2021 at 10:53 | history | edited | Flater | CC BY-SA 4.0 | added 634 characters in body |
| Feb 17, 2021 at 10:47 | history | edited | Flater | CC BY-SA 4.0 | added 634 characters in body |
| Feb 17, 2021 at 10:36 | history | answered | Flater | CC BY-SA 4.0 |