Editing Law of Demeter (section)

==Disadvantages==
Although the LoD increases the adaptiveness of a software system, it may result in having to write many [[wrapper method]]s to propagate calls to components; in some cases, this can add noticeable time and space overhead.<ref name=Basili/><ref name=BradApp>{{cite web |url=http://www.bradapp.com/docs/demeter-intro.html |title=Introducing Demeter and its Laws | last=Appleton | first=Brad |access-date=6 July 2013 |quote=A side-effect of this is that if you conform to LoD, while it may quite increase the maintainability and "adaptiveness" of your software system, you also end up having to write lots of little wrapper methods to propagate methods calls to its components (which can add noticeable time and space overhead).}}</ref><ref name=Pragmatic>{{cite web |url=http://pragprog.com/articles/tell-dont-ask |title=Tell, Don't Ask |publisher=The Pragmatic Programmers, LLC |access-date=6 July 2013 |quote=The disadvantage, of course, is that you end up writing many small wrapper methods that do very little but delegate container traversal and such. The cost tradeoff is between that inefficiency and higher class coupling.}}</ref>

At the method level, the LoD leads to narrow interfaces, giving access to only as much information as it needs to do its job, as each method needs to know about a small set of methods of closely related objects.<ref>{{cite book
 | chapter-url         = http://www.ccs.neu.edu/research/demeter/papers/law-of-demeter/oopsla88-law-of-demeter.pdf
 | title       = Conference proceedings on Object-oriented programming systems, languages and applications (OOPSLA '88)
 | chapter     = Object-Oriented Programming: An Objective Sense of Style
 | last1       = Lieberherr
 | first1      = K.
 | last2       = Holland
 | first2      = I.
 | last3       = Riel
 | first3      = A.
 | date        = 1988
 | publisher   = ACM |pages=323–334 |doi=10.1145/62083.62113 |editor-first=Norman |editor-last=Meyrowitz
 | quote       = Easier software maintenance, less coupling between your methods, better information hiding, narrower interfaces, methods which are easier to reuse, and easier correct.ness proofs using structural induction.
 | access-date  = 2012-07-05
| isbn       = 978-0897912846
 | s2cid = 562521
 }}</ref> On the other hand, at the class level, if the LoD is not used correctly, wide (i.e., enlarged) interfaces may be developed that require introducing many auxiliary methods.<ref name=BradApp/><ref name=Pragmatic/> This is due to poor design rather than a consequence of the LoD per se. If a wrapper method is being used, it means that the object being called through the wrapper should have been a dependency in the calling class.

One proposed solution to the problem of enlarged class interfaces is the [[Aspect-oriented programming|aspect-oriented]] approach,<ref name=AOP-Programming>{{cite journal
 |last1      = Lieberherr
 |first1     = Karl
 |last2      = Orleans
 |first2     = Doug
 |last3      = Ovlinger
 |first3     = Johan
 |date       = October 2001
 |title      = Aspect-oriented programming with adaptive methods
 |pages      = 39–40
 |journal    = Commun. ACM
 |volume     = 44
 |issue      = 10
 |doi        = 10.1145/383845.383855
 |quote      = An adaptive method encapsulates the behavior of an operation into one place, thus avoiding the scattering problem, but also abstracts over the class structure, thus avoiding the tangling problem as well.
 |citeseerx  = 10.1.1.192.6403
|s2cid = 2792493
 }}</ref> where the behavior of the method is specified as an aspect at a high level of abstraction. 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.