What is the Law of Demetrius?

7

In a contest quiz, I found the following question:

  

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

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

What is this Law about Demetrius?

    
asked by anonymous 30.06.2017 / 18:59

2 answers

6

You have a translation error there.

Wikipedia about such a law:

  

It is only 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 god dess of agriculture.

It is the name of the Goddess Demeter, or Demetra.

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

  

When object-oriented programs (...) an object A request to 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 can request a service (call a method) from an instance of object B, but object A can not" traverse "object B to access a third object. "

In his 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" accesses other objects that have been created by other methods, ie D alternative.

    
30.06.2017 / 19:13
2
Demetrio's Law or The Minimum Knowledge Principle guides us to reduce interactions between objects, advising us to encapsulate functions, routines, internal logic, 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 about the number of classes with which any object interacts and also how this interaction occurs ... This principle prevents us from creating projects with a large number of interconnected classes, which means that any change in one part of the system has a cascade effect on other parts "(Freeman, 2005: 221) The principle gives us some tips: we take any object, and from any method for 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 any components of the object.

source: link

    
30.06.2017 / 19:01