To those who understand the systemic character of the current market This post is helpful to understand the period between July 2007 through March 31 2009. In the absence of market pricing we have been conveyed contrivance, in the disconnect between supply and demand we get systemic obfuscation...the terms and methods of which are contained in programs that operate within rules for communicating between themselves. Codifying the awareness that RO/RS =CF in that a System is only as good as its sensory organs, and can be no better than its capacity to process information bi directionally....which the current iterated one fails to do completely (accept on behalf of the limited few who constitute house programmers as the loop).
Law of Demeter
From Wikipedia, the free encyclopedia
Jump to: navigation, search
The Law of Demeter (LoD), or Principle of Least Knowledge, is a design guideline for developing software, particularly object-oriented programs. The guideline was invented at Northeastern University towards the end of 1987, and can be succinctly summarized as “Only talk to your immediate friends.” The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).
It is so named for its origin in the Demeter Project, an adaptive programming and aspect-oriented programming effort. This project was named in honor of Demeter, “distribution-mother” and goddess of agriculture, to signify a bottom-up philosophy of programming which is also embodied in the law itself.
Note that it is debatable if bottom-up (or synthetic) is the correct analogy. It can be argued that software evolves or grows, which is appropriate given Demeter's mythological role.
When applied to object-oriented programs, the Law of Demeter can be more precisely called the “Law of Demeter for Functions/Methods” (LoD-F). In this case, an object A can request a service (call a method) of an object instance B, but object A cannot “reach through” object B to access yet another object, C, to request its services. Doing so would mean that object A implicitly requires greater knowledge of object B’s internal structure. Instead, B’s class should be modified if necessary so that object A can simply make the request directly of object B, and then let object B propagate the request to any relevant subcomponents. Or A should have a direct reference to object C and make the call directly. If the law is followed, only object B knows its own internal structure.
More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:
O itself
M's parameters
any objects created/instantiated within M
O's direct component objects
In particular, an object should avoid invoking methods of a member object returned by another method. For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as "use only one dot". That is, the code "a.b.Method()" breaks the law where "a.Method()" does not. There is disagreement as to the sufficiency of this approach.[1][2]
As a simple example, when one wants to walk a dog, it would be folly to command the dog’s legs to walk directly; instead one commands the dog and lets it take care of its legs itself. [3]
The advantage of following the Law of Demeter is that the resulting software tends to be more maintainable and adaptable. Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.
A disadvantage of the Law of Demeter is that it sometimes requires writing a large number of small “wrapper” methods (sometimes referred to as Demeter Transmogrifiers) 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.
Basili et al published experimental results in 1996 suggesting that the Law of Demeter was a valid way to reduce the probability of software faults. |
