Re: The Motivation and Explanation of LoD by Its Creators

From: Universe (no email)
Date: 11/08/04 

Date: Mon, 08 Nov 2004 06:38:30 -0500

For now I don't think I can say anything more than what I have on LoD.
But I will chime in now when I think I can help, or be helped.

And I'm sure time will help, and we will get farther along on LoD.

Elliott

Nicholls.Mark@mtvne.com (Mark Nicholls) wrote:

> Universe <> wrote in message news:<sqhqo0lalo68rdqf1jtlt80behqn50n08s@4ax.com>...
> > IV. The Motivation and Explanation [of LoD]
> >
> > [Excerpted from the original paper on LoD:
> > Object-Oriented Programming:
> > An Objective Sense of Style
> > K. Lieberherr, I. Holland, A. Riel]
> >
> > "The motivation behind this Law is to ensure that the
> > software is as modular as possible. Any method written
> > to obey this Law will only know about the immediate
> > structure of the class to which it is attached.
>
> OK....so it is about non utopian (in the sense of my other post) SD.
>
> i.e. to me this structure would not be available in a utopian set of
> classes.
>
> > "The structure of the arguments and the sub-structure
> > of C are hidden from M.
>
> ahhh, but this is a statement about structure hiding.
>
> > Therefore, should a change
> > to the structure of the class C be necessary we need
> > only to look at those methods attached to C and
> > its subclasses for possible conflicts. The Law effectively
> > reduces the occurrences of certain nested message
> > sendings (generic function calls) and simplifies
> > the methods. The Law prohibits the nesting of generic
> > accessor function calls, which return objects that are
> > not instance variable objects. It allows the nesting
> > of constructor function calls. An accessor function is
> > a function which returns an object which did exist
> > before the function is called. A constructor function
> > returns an object which did not exist before the function
> > is called.
> > "The Law of Demeter has many implications regarding
> > widely known software engineering principles.
> > Our contribution is to condense many of the proven
> > principles of software design into a single statement
> > September 25-30,1988 OOPSLA ?88 Proceedings 325
> > which can easily be used by the object-oriented programmer
> > and which can be easily checked at compile time.
> > "Some of the inter-related principles covered by the
> > Law are the following:
> >
> > * Coupling control.
> > "It is a well-known principle of software design to
> > have minimal coupling between abstractions (e.g.
> > procedures, modules, methods) [3]. The coupling
> > can be along several links. An important link for
> > methods is the ?uses? link (or call/return link)
> > which is established when one method calls another
> > method. The Law of Demeter effectively
> > reduces the methods we can call inside a given.
> > a method and therefore limits the coupling of
> > methods with respect to the ?uses? relation. The
> > Law therefore facilitates reusability of methods
> > and the abstraction level of the software.
> >
>
> OK
>
> > * Information hiding.
> > "The Law of Demeter enforces one kind of information
> > hiding: structure hiding. In general, the
> > Law prevents a method from directly retrieving
> > a subpart of an object which lies deep in that object?s
> > ?part-of? hierarchy.
>
> hmmm, this is problematic to me, for it to be a subpart is fine, the
> class knows it's own parts (though I dislike it, as 'part' seems
> subjective).
>
> but for it to know what constitutes a part of a part, to me seems
> weak, in general it doesn't....thus it must consider all returned
> objects to be potentially parts...this is probably too restrictive.
>
> > Instead, intermediate
> > methods must be used to traverse the ?part-of?
> > hierarchy in controlled small steps [12], [3].
>
> where do these methods live?
>
> > In some object-oriented systems, the user can
> > protect some of the instance variables or methods
> > of a class from outside access by making them
> > private. This important feature complements the
> > Law to increase modularity but is orthogonal to
> > it. Our Law promotes the idea that the instance
> > variables and methods which are public should
> > be used in a restricted way.
>
> hmmm. again, it seems to be saying "buyer beware" i.e. it is a client
> oriented heiristic. Encapsulation and information hiding, are indeed
> orthogonal i.e. service related.
>
> >
> > * Information restriction.
> > "Our work is related to the work by Parnas et
> > al. [15] [14] on the modular structure of complex
> > systems. To reduce the cost of software changes
> > in their operational flight program for the A-7E
> > aircraft, the use of modules that provide information
> > that is subject to change is restricted. We
> > take this point of view seriously in our object oriented
> > programming and assume that any class
> > could change. Therefore we restrict the use of
> > message sendings (generic function calls) by the
> > Law of Demeter. Information restriction complements
> > information hiding. Instead of hiding
> > certain methods, we make them public but we
> > restrict their use.
> >
>
> and this is the nub(!) of the issue.
>
> LoD appears to be the safety net....potentially dangerous methods are
> made public, yet if clients obey LoD, the impact of any change is
> minimised.
>
> > * Localization of information.
> > "The importance of localizing information is
> > stressed in many software engineering texts. The
> > Law of Demeter focuses on localizing type information
> > When we study a method we only have to
> > be aware of types which are very closely related
> > to the class to which the method is attached. We
> > can effectively be ignorant (and independent) of
> > the rest of the system and as the old proverb
> > goes: ?Ignorance is bliss?. This is an important
> > aspect which helps to reduce the complexity of
> > programming.
>
> OK, I buy this, but "closely related", is a difficult term. How do I
> know if something is closely related or not, if I need to interact
> with it in order to satisfy my specification, then is it not closely
> related by definition.
>
> > "From another point of view related to localization,
> > the Law controls the visibility of message
> > names. In a given method we can only use message
> > names which are in the signatures of the
> > instance variable types and argument types.
> > Narrow interfaces.
> > "The maintenance of narrow interfaces between
> > interacting entities is also important (see e.g.
> > 112, page 3031). A method should have access
> > to only as much information as it needs to do
> > its job. ,If a method gets too much information,
> > it has to destructure this information (via many
> > nested sends) which the Law of Demeter discourages.
> > Therefore The Law promotes narrow interfaces
> > between methods."
> >
>
> hmmm, I'm not too sure about this bit.
>
> > Found at:
> > http://www.ccs.neu.edu/research/demeter/papers/law-of-demeter/oopsla88-law-of-demeter.pdf
> >
>
> OK, it's interesting, I don't disbelieve it, but I think it's a safety
> net encouraging safe localised interactions...but the central onus is
> (to me) on the service class.

Relevant Pages

  • Re: Re: Opinions on the Law Of Demeter
    ... > that it can save law of demeter in a fundamental way. ... Cozianu latches onto a surface non-essetial thing about ... LoD and then stretches and pounces on it attempting to make something ...
    (comp.object)
  • Re: Re: Opinions on the Law Of Demeter
    ... LoD originated in Structured programming. ... The Law effectively ... hiding: structure hiding. ...
    (comp.object)
  • Re: Re: Opinions on the Law Of Demeter
    ... content of LoD lies at the core of competent software engineering. ... "A more general formulation of the Law of Demeter is: ... Lieberherr, Karl. ...
    (comp.object)
  • Re: Re: Opinions on the Law Of Demeter
    ... I will quote the Law of Demeter as ... The LoD is a *quite* reasonable heuristic whose big picture aim is to ... system design architectures ...
    (comp.object)
  • Re: Opinions on the Law Of Demeter
    ... Before trying to apply LOD the only dependency was that its client might ... That;s the kind of style that the Law of Demeter encourages and that's why ...
    (comp.object)