Talk:Law of Demeter

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)

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

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. 150.101.156.249 (talk) 06:08, 25 August 2011 (UTC)