What is the Demetrius Law about?

Question

In a contest, I found the following question:

In Object-Oriented Programming, the law of Demetrius (Law of Demeter) says that a method m of an O object should not invoke methods of following object types: (A) of O itself. (B) parameters of m. (C) any object created/instantiated in m. (D) objects returned by called other methods. (E) O attributes. (Specific Knowledge - System Analyst - q54 - 2013 )

Among these, the right answer would be "(C) any object created/instantiated in m" according to the template.

What’s this Demetrius Law about?

Answer 1

There’s a translation error there.

Wikipedia on that law:

It is so named for its origin in the Demeter Project, an adaptive Programming and Aspect-oriented Programming effort. The project was named in honor of Demeter, "Distribution-Mother" and the Greek Goddéss of Agriculture.

It’s the name of the goddess Demeter, or Demetra.

Otherwise, such a law says that a unit of code must know and communicate only with those units closest to it that are directly related to it. Again from the wiki:

When Applied to Object-oriented Programs(...) an Object A can request a service (call a method) of an Object instance B, but Object A should not "Reach through" Object B to access yet Another Object

"When applied to OO (...) an object A may request a service (call a method) from an object instance B, but object A cannot "traverse" object B to access a third object".

In your case, the "m" method can access his father (type "O"), his brothers (other members of "O"), his own parameters etc. The law is violated if "m" access other objects that were created by other methods, i.e., alternative D.

Answer 2

Demetrio’s Law or The Minimum Knowledge Principle guides us to reduce interactions between objects, advising us to encapsulate functions, routines, internal logics and systems. A system with many dependencies between multiple classes is a fragile system, difficult to maintain and too complex to be understood by all.

"This means that, when designing a system, we must be careful with the number of classes with which any object interacts and also with the way this interaction occurs (...) This principle prevents us from creating projects with a large number of interconnected classes, which causes any change in one part of the system to have a ripple effect on other parts." (Freeman, 2005, p. 221) The principle gives us some hints: we take any object and, from any method to that object, we can only invoke methods that belong to the object itself, to objects that have been passed as parameters to the method, to any object that is created or instantiated by the method and finally to any components of the object.

source: https://ferhenriquef.com/2010/07/18/principios-de-projetos-orientados-a-objetos/