Re: Opinions on the Law Of Demeter

From: Daniel T. (postmaster_at_earthlink.net)
Date: 11/08/04 

Date: Mon, 08 Nov 2004 12:12:37 GMT

In article <2v8253F2id5odU2@uni-berlin.de>,
 Costin Cozianu <c_cozianu@hotmail.com> wrote:

> Daniel T. wrote:
>
> > Costin Cozianu <c_cozianu@hotmail.com> wrote:
> >
> >
> >>Daniel T. wrote:
> >>
> >>
> >>>Costin Cozianu <c_cozianu@hotmail.com> wrote:
> >>>
> >>>
> >>>
> >>>>Which was my point (I gave you the examples with the Visitor pattern
> >>>>whioch creates even more unwarranted complexity). These "advanced"
> >>>>techniques are not going to improve on lines of code such as
> >>>>
> >>>>System.out.println( customer.getContact().getEmail());
> >>>>
> >>>>Such lines of code are better dealt them with letting them be, even if
> >>>>they violates Demeter. Because the Law of Demeter is a very bad
> >>>>predictor of the quality of the code.
> >>>
> >>>
> >>>The confusion here is that the above line of code does not necessarily
> >>>break the LoD, so to summarily say that LoD code is more complicated
> >>>than it is wrong.
> >>>
> >>>In fact, the code above does not require the Customer class to contain a
> >>>contact object, nor does it require the Contact class to contain a
> >>>String representing of the contact's email, so it doesn't break the LoD.
> >>
> >>Let me explain this to you:
> >>The above code gets a temporary object inside the scope of the method
> >>that object is of class Contact, not Customer (regardless whether
> >>Customer class "contains" a Contact object or not), so as per LOD you
> >>are not allowed to call methods of that object.
> >
> >
> > Your explanation is wrong. From the original paper:
> >
> > """
> > The Law prohibits the nesting of generic
> > accessor function calls... 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.
> > """
> >
> > If getContact() is a constructor function, then there is absolutely
> > nothing wrong with the code as far as LoD is concerned.
>
> Admitting that getContact() is a constructor you are right. But why
> should getCOntact() construct a new object when typically such objects
> are typically read only (i.e they have no modifying methods) ?

You keep moving the goal posts... If the Contact class produces
immutable objects then you are absolutely right; any method that returns
one can be considered a constructor method. Let's call this an
exception, the one place where LoD can be broken without problems.

Of course C++ is a special case because there is still the question of
ownership, in that case, I would still produce a copy.

> >>But just assume that the Customer class "contains" a Contact object and
> >>that object is returned by getContact().
> >>
> >>So please show me what you replace
> >>
> >>doSomethingWith ( Customer c)
> >>...
> >> System.out.println( c.getContact().getEmail());
> >>...
> >>}
> >>
> >>with, and how that whatever something is better, by any objective measure.
> >
> >
> > I would turn getContact into a constructor function, there is no need to
> > change the client code at all. IE:
> >
> > class Customer {
> > public Contact getContact() {
> > // create a new Contact object and return it
> > }
> > }
> >
> > By changing the Customer class in this way, I am assured that no client
> > code will be dependent on Customer containing a Contact object.
>
> But no client is dependent regardless. You don't need to produce a clone
> of the contained Contact object if the Contact object is unmodifiable.

Given your assumption that a Contact object is immutable, you are
correct.

> (Like it should be in most such cases).

Here, I don't agree. A classic definition of a class (ie Booch) is that
it has identity, state, and behavior that modifies that state. Most
classes in an OO program should have methods that modify their state. If
most classes are immutable, then you are producing a functional (as in
functional languages) solution, not an OO solution.

Don't get me wrong here, I'm not saying that functional language
solutions are incorrect, I'm simply saying that they aren't OO.

Relevant Pages

  • Re: Opinions on the Law Of Demeter
    ... > of constructor function calls. ... >> that object is returned by getContact(). ... > change the client code at all. ... > By changing the Customer class in this way, I am assured that no client ...
    (comp.object)
  • Re: Opinions on the Law Of Demeter
    ... >>that object is of class Contact, not Customer (regardless whether ... > of constructor function calls. ... Admitting that getContact() is a constructor you are right. ... But no client is dependent regardless. ...
    (comp.object)
  • Re: Re: Opinions on the Law Of Demeter
    ... >> of constructor function calls. ... > Admitting that getContact() is a constructor you are right. ... >> code will be dependent on Customer containing a Contact object. ... > But no client is dependent regardless. ...
    (comp.object)