Talk:Law of Demeter

Citation 2

It is not actually a link to any evidience of a disadvantage in terms of preformance, please link to something correct! — Preceding unsigned comment added by 122.106.254.100 (talk) 11:30, 31 March 2012 (UTC)

In object-oriented programming

The cited reference for the 5 points listed in this section slightly contradicts some of the 5 points. The reference only details 4 points. Point one and point five are not listed in the reference. Point is is the "method" itself, not the object, and point four and one in the article are really the same. The cited reference *never* details global variables. Ritchiep (talk) 19:45, 19 November 2012 (UTC)

Origin of the name

What does this law have to do with Demeter? -- Smerdis of Tlön 18:08, 8 Apr 2004 (UTC)

(Inserted quote from Wikipedia:Featured article removal candidates/Law of Demeter):

Not voting, just info for Smerdis: it's named for the Demeter Project, during which it was formulated. The Demeter Project was so named because it was trying to develop software methodolgies which "grew" organically, and Demeter is the goddess of agriculture. Securiger 09:19, 12 May 2004 (UTC)

For the curious. Shinobu 18:06, 25 November 2006 (UTC)

I disagree with the origin of the name - I was taught it was based on the Greek myth of Persephone, where Persephone (daughter of Demeter) was abducted by Hades. Thus, using the dark humor found so often in Comp Sci, the LoD boils down to "don't talk to strangers". Perhaps the origin is a bit of both (I would expect people on the Demeter Project to be aware of associated stories). 2603:300B:727:C700:4DD5:2EF0:DDE8:B56C (talk) 20:38, 24 March 2021 (UTC)

What does this mean?

No further work has been conducted using the Law since 1996. However, it is still taught in less up-to-date computer science curriculums.

What is the intended meaning of these two sentences? Shinobu 18:02, 25 November 2006 (UTC)

Shinobu, we have to talk. 134.106.199.22 15:07, 12 April 2007 (UTC)

Surely this "law" (I'd call it a principle) is older than 1987? In my opinion, this is what all "good" object-oriented systems strive toward. MagnusW 11:36, 19 June 2007 (UTC)

Disadvantage paragraph

I find this paragraph in the disadvantages very obscure: "One solution to the problem of enlarged class interfaces is the aspect-oriented approach,[7] where the behavior of the method is specified as an aspect at a high level of abstraction. This is done by having an adaptive method that encapsulates the behaviour of an operation into a place, with which the scattering problem is solved. It also abstracts over the class structure that results in avoiding the tangling problem. The wide interfaces are managed through a language that specifies implementations. Both the traversal strategy and the adaptive visitor use only a minimal set of classes that participate in the operation, and the information about the connections between these classes is abstracted out." What is the "tangling problem" and "scattering problem"? "Traversal strategy" and "adaptive visitor"? This sounds like some kind of enterprise architecture pattern pulled out of its place and put into this article out of context. I think it's great to suggest solutions to software design principles, but something like this seems like it needs its own article, it doesn't make sense here... Davedx (talk) 07:58, 23 January 2018 (UTC)

Off-topic discussion collapsed

This paragraph is just plain wrong: ""A disadvantage of the Law of Demeter is that it sometimes requires writing a large number of small "wrapper" methods to propagate method calls to the components. Furthermore, a class's interface can become bulky as it hosts methods for contained classes, resulting in a class without a cohesive interface. But this might also be a sign of bad OO design."" It is indeed a sign of bad OO design and has nothing to do with the Law of Demeter. What is this paragraph talking about? --150.101.156.249 (talk) 04:57, 27 May 2011 (UTC) For example, if we have a Person class with a .friends member, Law of Demeter suggests encapsulating the collection rather than exposing it directly; therefore, we would define Person.addFriend(), Person.removeFriend(), etc. Now assume Person also has .relatives, .coworkers, etc. The number of trivial delegation methods starts to multiply. Dunno if lack of "a cohesive interface" is the best characterization of the problem though. --Cybercobra (talk) 19:09, 27 May 2011 (UTC) That is an example of sweeping a code-smell under the rug so that it technically compiles with the law, instead of actually addressing the problem. This example suggests that the function in question should be operating on the friends array, not on the Person object. i.e. the function should've been passed person.friends as an argument, not person (which does not require trivial delegation methods at all). The problem in your example was that you have a function that wants to operate on a friends collcetion, but is being forced to access it via an intermediate class (which the function doensn't require knowledge of). You've simply made the intermediate/unnecessary class more complex, while maintaining it as a dependency of the function, instead of achieving the purpose of the law, which is to remove the unnecessary dependency by passing the correct arguments to begin with. If, in applying the law, you end up with lots of these small "wrapper" methods, then you're not actually achieving the purpose/spirit of this law at all. 150.101.156.249 (talk) 06:08, 25 August 2011 (UTC) The LoD is more suited to addressing issues with composition/encapsulation, where the composition makes sense. It is illogical for a person to be composed of a friends list. Rather, there should be an aggregate association of friends as part of a higher-level abstraction of say, a PersonsProfile. This higher abstraction is better suited for storing such relations. The principle of least knowledge now comes into play: should PersonsProfile expose the composite interfaces, or should it expose an abstraction. In order to add a new Friend association to the Person, should the API expose PersonsProfile.getFriends() or PersonsProfile.addFriend()? Well, if you expose PersonsProfile.getFriends() there likely already exists an Friends.add() method. This approach clearly breaks encapsulation, but avoids the requirement of writing a forwarding/wrapper method; if the Friends interface changes, all client code dependent on that interface must be adapted. If, alternatively, you expose PersonsProfile.addFriend() you avoid the dependency but have to code the abstraction up front; this maintains encapsulation, but adds both time and space overhead. The decision is not as black and white as Mr. Anonymous tries to portray above; this is especially true in performance-critical sections. I do think that, in most cases, encapsulation should be preferred; but as the old saying goes, laws are meant to be broken. — Preceding unsigned comment added by Jamarr81 (talk • contribs) 21:06, 7 June 2013 (UTC) I think the 'friendsList' example was purely to show how you need to add extra methods to a class if you want to avoid calling 'through' it to some distant class. I don't believe it was intended as an example of a good structure for an object of type 'Person'. I'd go further and say it's annoying when people take code examples too literally without considering what the author was trying to convey. If you put a code sample up in nearly any context (to explain a simple idea) it is fairly easy to criticize it for reasons that are unrelated. LegendLength You should really re-read the whole dialog. I was not disagreeing with or criticizing Cybercobra. I was actually trying to expand upon his comment to help demonstrate (perhaps poorly) to "Mr. Anonymous" that there are legitimate cases where the "Law of Demeter" breaks down. Jamarr81 (talk) 19:08, 1 March 2016 (UTC) The underlying problem is that unfortunately a lot of programmers think they are puppeteers and must move the dog's legs, instead of just asking the dog to walk. So it boils down to a lack of abstraction. Breaking the Law of Demeter is typically a symptom of micromanagement, a mindset that you need to "pull the strings" to make things happen. If you can not get rid of that ill guided mindset, no amount of refactoring and recasting of calls can save you. 188.174.33.85 (talk) 10:34, 18 May 2019 (UTC)

Note: This is not a forum general discussion of OOP. I have therefore collapsed the discussion about the pros and cons of the law. Please keep the discussion focused on discussing actual improvements to the article. Disadvantages and advantages should come from WP:Reliable sources, not the editor's opinions. --Averell (talk) 06:50, 20 May 2019 (UTC)