Search the web
Sign In
New User? Sign Up
extremeprogramming · Extreme Programming
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Want your group to be featured on the Yahoo! Groups website? Add a group photo to Flickr.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
The Law of Demeter and Testability   Topic List   < Prev Topic  |  Next Topic >
Summarize Messages Sort by Date  
#122627 From: "Jay Flowers" <jay.flowers@...>
Date: Mon Sep 11, 2006 8:00 pm
Subject: The Law of Demeter and Testability
jfl0wers
Offline Offline
Send Email Send Email
 
The Law of Demeter and Testability
<http://jayflowers.com/WordPress/?p=78> Monday,
September 11th, 2006

The Law of Demeter, also know as the Principle of Least Knowledge, is
important to controlling the type population of a test subject. Here is a
fun explain from c2.com:

- You can play with yourself.
- You can play with your own toys (but you can't take them apart),
- You can play with toys that were given to you.
- And you can play with toys you've made yourself.

------------------------------

Explanation in plain English:

- Your method can call other methods in its class directly
- Your method can call methods on its own fields directly (but not on
the fields' fields)
- When your method takes parameters, your method can call methods on
those parameters directly.
- When your method creates local objects, that method can call method
on the local objects.

------------------------------

The paper Mock Roles, not
Objects<http://www.jmock.org/oopsla2004.pdf#search=%22mock%20roles%20not%20objec\
ts%22
>
contains
a good example:

dog.Body.Tail.Wag();

should really be:

dog.ExpressHappiness();

To be clear the example code above would be contained in the test subject.
The bad example couples the test subject to DogAnimal, DogBody, and DogTail.
Where as the good example couples only to DogAnimal. This smell has always
reminded me of a violation of the Single Responsibility Principle.
These symptoms indicate a violation of the Law of Demeter:

- To Many Mock Objects
- To Much Mock Setup
- Mock Object Chaining

"Compliance to the Law of Demeter reduces the number of interfaces, the
number of stubs and drivers that may be needed, and the number of
integration test interfaces." - Reviewing Software Artifacts for
Testability<http://www.informatik.fernuni-hagen.de/pi3/PDFs/EuroSTAR99.pdf#searc\
h=%22Reviewing%20Software%20Artifacts%20for%20Testability%22
>
by
Stefan Jungmayr

Interestingly Endo-Testing Unit Testing with Mock
Objects<http://www.ccs.neu.edu/research/demeter/related-work/extreme-programming\
/MockObjectsFinal.PDF
>
by
Tim Mackinnon, Steve Freeman and, Philip Craig presents the view that "…code
developed with Mock Objects tends to conform to the Law of Demeter, as an
emergent property. The unit tests push us towards writing domain code that
refers only to local objects and parameters, without an explicit policy to
do so." I am not so sure that use of mocks naturally leads to conformance
to the Law of Demeter. Martin Fowler noticed that developers that perform
interaction based testing tend to follow the Law of Demeter (Mocks Aren't
Stubs <http://www.martinfowler.com/articles/mocksArentStubs.html>):

"Interaction-based testers do talk more about avoiding 'train wrecks' -
method chains of style of getThis().getThat().getTheOther(). Avoiding method
chains is also known as following the Law of Demeter. While method chains
are a smell, the opposite problem of middle men objects bloated with
forwarding methods is also a smell. (I've always felt I'd be more
comfortable with the Law of Demeter if it were called the Suggestion of
Demeter.) One of the hardest things for people to understand in OO design
is the "Tell Don't Ask"
principle<http://www.amazon.com/exec/obidos/ASIN/020161622X>,
which encourages you to tell an object to do something rather than rip data
out of an object to do it in client code. Interaction testers say that using
interaction testing helps promote this and avoid the getter confetti that
pervades too much of code these days."

Mock Object
Patterns<http://hillside.net/plop/plop2003/Papers/Brown-mock-objects.pdf#search=\
%22%22Law%20of%20Demeter%22%20testability%22
>
by
Matthew A. Brown and Eli Tapolcsanyi includes the pattern Pass in Mock
Collaborator. In the implementation section of the pattern they direct you
to use "… the Law of Demeter, design your method calls to permit easy
testing" of the test subject.

I think the basic underlining issue with violations of the Law of Demeter is
misplaced responsibility. I suspect that this is why it is also called the
Principle of Least Knowledge and why it reminds me of the Single
Responsibility Principle. Part of correctly assigning responsibility is
dependency management an testability is very sensitive to dependency issues.



Side Note:

Some people get concerned about interaction based testing coupling the unit
test to the implementation of the test subject. It can if a test double is
used in place of an object that the test subject uses as a helper (i.e. the
interaction of the test subject with the helper is not a responsibility of
the test subject). In general you should only ever use test doubles where
it is the responsibility of the test subject to perform the interaction.
Please notice I said responsibility of the test subject and not the system.
A test subject plays a role in a system and that role has responsibilities
which include interaction, maybe even entirely comprised of, with other
objects in the system. When you refactor a class, or test subject, in a
system it is still responsible for interacting with the same objects it did
before the refactoring. When you change its interactions, or move the
responsibility to an other class, you are refactoring the system. When
refactoring the system unit tests should break. When refactoring a class
unit tests should not break.


--
Jay Flowers
----------------------------------------------------------------------
http://jayflowers.com
---------------------------------------------------------------------


[Non-text portions of this message have been removed]




#122641 From: "jeffz_2002" <jeffz_2002@...>
Date: Tue Sep 12, 2006 2:48 pm
Subject: Re: The Law of Demeter and Testability
jeffz_2002
Offline Offline
Send Email Send Email
 
I'm hoping someone can clear up this nagging question ...

> a good example:
> dog.Body.Tail.Wag();
> should really be:
> dog.ExpressHappiness();

I can understand that the first example is fragile in the face of
code
changes ... what I'm not clear on is how to get from
dog.ExpressHappiness() to Tail.Wag().

If the client used dog.Body.Tail.Wag(), then the client has too much
knowledge about dog and its components ... bad. Any change to the
dog
classes could force client changes.

But if we do dog.ExpressHappiness(), then wouldn't the code in dog be:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.Tail.Wag();
}

and isn't this also a violation of Demeter, even if it's internal to
Dog? If I wrote the dog class, and someone else wrote the Body
class,
would it be better to have the following in Body:

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.Wag();
}

Or, would you even go further ... after all, should Body /really/ be
telling Tail how to go about expressing happiness?

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.ExpressHappiness();
}

// in Tail
public void ExpressHappiness() throws NoTailException {
this.Wag();
}

And then:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.ExpressHappiness();
}

It seems a bit silly ... now every component in the chain has
ExpressHappiness. I think I'm carrying the idea too far, but I'd
like
some feedback.

Thanks for hearing me out.

Jeff







#122642 From: "David Moye" <cdmoye@...>
Date: Tue Sep 12, 2006 3:25 pm
Subject: RE: [XP] Re: The Law of Demeter and Testability
cdmoye
Offline Offline
Send Email Send Email
 
I assume it would be something like:



dog.ExpressHappiness()



which looks like:

Body.WagTail()



which looks like:

Tail.Wag()



David





_____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of jeffz_2002
Sent: Tuesday, September 12, 2006 10:49 AM
To: extremeprogramming@yahoogroups.com
Subject: [XP] Re: The Law of Demeter and Testability



I'm hoping someone can clear up this nagging question ...

> a good example:
> dog.Body.Tail.Wag();
> should really be:
> dog.ExpressHappiness();

I can understand that the first example is fragile in the face of
code
changes ... what I'm not clear on is how to get from
dog.ExpressHappiness() to Tail.Wag().

If the client used dog.Body.Tail.Wag(), then the client has too much
knowledge about dog and its components ... bad. Any change to the
dog
classes could force client changes.

But if we do dog.ExpressHappiness(), then wouldn't the code in dog be:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.Tail.Wag();
}

and isn't this also a violation of Demeter, even if it's internal to
Dog? If I wrote the dog class, and someone else wrote the Body
class,
would it be better to have the following in Body:

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.Wag();
}

Or, would you even go further ... after all, should Body /really/ be
telling Tail how to go about expressing happiness?

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.ExpressHappiness();
}

// in Tail
public void ExpressHappiness() throws NoTailException {
this.Wag();
}

And then:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.ExpressHappiness();
}

It seems a bit silly ... now every component in the chain has
ExpressHappiness. I think I'm carrying the idea too far, but I'd
like
some feedback.

Thanks for hearing me out.

Jeff





[Non-text portions of this message have been removed]




#122643 From: "David Moye" <cdmoye@...>
Date: Tue Sep 12, 2006 3:35 pm
Subject: RE: [XP] Re: The Law of Demeter and Testability
cdmoye
Offline Offline
Send Email Send Email
 
I hate to reply to my own mail, but I thought I needed to add some
reasoning. Mostly I think that Jeff was making one misstep. Body doesn't
need to know why it's supposed to wag the tail and Tail doesn't need to know
why it's being wagged. Therefore, there's no reason for each of them to have
an ExpressHappiness method. They can get away with just the mechanical
processes.



David



_____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of David Moye
Sent: Tuesday, September 12, 2006 11:26 AM
To: extremeprogramming@yahoogroups.com
Subject: RE: [XP] Re: The Law of Demeter and Testability



I assume it would be something like:

dog.ExpressHappiness()

which looks like:

Body.WagTail()

which looks like:

Tail.Wag()

David

_____

From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
[mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com] On Behalf Of jeffz_2002
Sent: Tuesday, September 12, 2006 10:49 AM
To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
Subject: [XP] Re: The Law of Demeter and Testability

I'm hoping someone can clear up this nagging question ...

> a good example:
> dog.Body.Tail.Wag();
> should really be:
> dog.ExpressHappiness();

I can understand that the first example is fragile in the face of
code
changes ... what I'm not clear on is how to get from
dog.ExpressHappiness() to Tail.Wag().

If the client used dog.Body.Tail.Wag(), then the client has too much
knowledge about dog and its components ... bad. Any change to the
dog
classes could force client changes.

But if we do dog.ExpressHappiness(), then wouldn't the code in dog be:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.Tail.Wag();
}

and isn't this also a violation of Demeter, even if it's internal to
Dog? If I wrote the dog class, and someone else wrote the Body
class,
would it be better to have the following in Body:

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.Wag();
}

Or, would you even go further ... after all, should Body /really/ be
telling Tail how to go about expressing happiness?

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.ExpressHappiness();
}

// in Tail
public void ExpressHappiness() throws NoTailException {
this.Wag();
}

And then:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.ExpressHappiness();
}

It seems a bit silly ... now every component in the chain has
ExpressHappiness. I think I'm carrying the idea too far, but I'd
like
some feedback.

Thanks for hearing me out.

Jeff

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]




#122646 From: "jeffz_2002" <jeffz_2002@...>
Date: Tue Sep 12, 2006 5:08 pm
Subject: [XP] Re: The Law of Demeter and Testability
jeffz_2002
Offline Offline
Send Email Send Email
 
> Body doesn't need to know why it's supposed to wag the tail ...

But does body even know about tail wagging? Doesn't body just ask the
tail to express something, and the tail responds by wagging?

It boils down to having an object (dog) that is linked to another
object (tail) via a long chain (e.g. dog.body.tail). The "inner
object" (tail, not directly reachable by the client) does something
special, but only the "outer object" (dog) can receive messages asking
for this special thing to occur ("outer object" is like an Aggregate
object as defined in Domain Driven Design). Doesn't chaining the calls
from the dog to the tail break Demeter?

It seems like an academic argument, but I have trouble seeing how to
*not* break Demeter, either in client code (such as "/*client code*/
dog.body.tail.wag;") or internally (such as "/*in dog implementation*/
public void expressHappiness { this.body.tail.wag; } )", in cases like
this. If there's a distinction made for Demeter with implementation
code, I've missed it.

Jeff







#122675 From: "Kevin Lawrence" <kev.lawrence@...>
Date: Wed Sep 13, 2006 3:25 pm
Subject: Re: [XP] Re: The Law of Demeter and Testability
kevinwilliam...
Offline Offline
Send Email Send Email
 
On 9/12/06, jeffz_2002 <jeffz_2002@...> wrote:
> > Body doesn't need to know why it's supposed to wag the tail ...
>
> But does body even know about tail wagging? Doesn't body just ask the
> tail to express something, and the tail responds by wagging?
>

What is the Body for ? Why can't the Dog just have a Tail ?

YAGNI Body

Kevin



#123213 From: "Paul Campbell" <yahoo@...>
Date: Fri Oct 6, 2006 9:48 am
Subject: LoD - just say no (for domain objects at least)
pncampbell99
Offline Offline
Send Email Send Email
 
--- In extremeprogramming@yahoogroups.com, "David Moye" <cdmoye@...>
wrote:

> If the client used dog.Body.Tail.Wag(), then the client has too much
> knowledge about dog and its components ... bad. Any change to the
> dog
> classes could force client changes.

I dissgree. The structural relationships between dog body and tail are
intrinsic to the problem domain and therefore afferent dependencies on
them are a *good* thing because they represent the minimal essential
dependencies on the problem domain concepts. I see no reason why we
should discard one of OO's most powerful and expressive constructs:
the use of object references to convey structural semantics so long as
it is used appropriatly i.e. in the problem domain.

Attempting to "insulate" clients from dependency on problem domain
concepts is always counter productive because such a dependency is the
minimum useful dependency - if a client doesnt need to know about a
problem domain relationship then that problem domain concept probably
doesnt need to exist in the domain model at all. The fact, therefore,
that a concept does exist in the problem domain model means that it is
right and proper that dependencies on it exist at all layers in the
application. If we try to "facade" away these dependecies we just
create more code that needs changing to cope with changes in domain
concepts and therefore make ourselves less agile.

If were talking about classes to collaberate to implement those
problem domain concepts then thats a different matter and LoD is
applicable here. I would just NEVER apply it to problem space concept
level classes (i.e. "domain" classes).

Paul.







#122645 From: "Robert Hanson" <robert.hanson@...>
Date: Tue Sep 12, 2006 4:54 pm
Subject: RE: [XP] Re: The Law of Demeter and Testability
mvarobert1
Offline Offline
Send Email Send Email
 
I have a couple of dogs, and for sure it is not enough to just wag a
tail to express happiness. Without getting too much into the design of
the class, it is entirely appropriate for you to have a
"expressHappiness" method, and leave the implementation of how a dog
exactly expresses happiness to the guts of that method.



For example, I have one dog that expresses happiness by shifting the
earset and changing it's posture a little bit, but hardly ever wags her
tail.



And I have another dog that wags its tail so hard that I'm worried it
will put dents into the sheetrock.



Maybe the best approach in this case is a strategy pattern, where the
mechanics of how happiness is expressed is delegated to a strategy
object that matches the individual dog represented by the instance of
"dog".



________________________________

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of David Moye
Sent: Tuesday, September 12, 2006 10:35 AM
To: extremeprogramming@yahoogroups.com
Subject: RE: [XP] Re: The Law of Demeter and Testability



I hate to reply to my own mail, but I thought I needed to add some
reasoning. Mostly I think that Jeff was making one misstep. Body doesn't
need to know why it's supposed to wag the tail and Tail doesn't need to
know
why it's being wagged. Therefore, there's no reason for each of them to
have
an ExpressHappiness method. They can get away with just the mechanical
processes.

David

_____

From: extremeprogramming@yahoogroups.com
<mailto:extremeprogramming%40yahoogroups.com>
[mailto:extremeprogramming@yahoogroups.com
<mailto:extremeprogramming%40yahoogroups.com> ] On Behalf Of David Moye
Sent: Tuesday, September 12, 2006 11:26 AM
To: extremeprogramming@yahoogroups.com
<mailto:extremeprogramming%40yahoogroups.com>
Subject: RE: [XP] Re: The Law of Demeter and Testability

I assume it would be something like:

dog.ExpressHappiness()

which looks like:

Body.WagTail()

which looks like:

Tail.Wag()

David

_____

From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
[mailto:extremeprogramming@
<mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com] On Behalf Of jeffz_2002
Sent: Tuesday, September 12, 2006 10:49 AM
To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
Subject: [XP] Re: The Law of Demeter and Testability

I'm hoping someone can clear up this nagging question ...

> a good example:
> dog.Body.Tail.Wag();
> should really be:
> dog.ExpressHappiness();

I can understand that the first example is fragile in the face of
code
changes ... what I'm not clear on is how to get from
dog.ExpressHappiness() to Tail.Wag().

If the client used dog.Body.Tail.Wag(), then the client has too much
knowledge about dog and its components ... bad. Any change to the
dog
classes could force client changes.

But if we do dog.ExpressHappiness(), then wouldn't the code in dog be:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.Tail.Wag();
}

and isn't this also a violation of Demeter, even if it's internal to
Dog? If I wrote the dog class, and someone else wrote the Body
class,
would it be better to have the following in Body:

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.Wag();
}

Or, would you even go further ... after all, should Body /really/ be
telling Tail how to go about expressing happiness?

// in Body
public void ExpressHappiness() throws NoTailException {
this.Tail.ExpressHappiness();
}

// in Tail
public void ExpressHappiness() throws NoTailException {
this.Wag();
}

And then:

// in Dog
public void ExpressHappiness() throws NoTailException {
this.Body.ExpressHappiness();
}

It seems a bit silly ... now every component in the chain has
ExpressHappiness. I think I'm carrying the idea too far, but I'd
like
some feedback.

Thanks for hearing me out.

Jeff

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]




#122663 From: George Dinwiddie <lists@...>
Date: Wed Sep 13, 2006 1:09 am
Subject: Re: [XP] Re: The Law of Demeter and Testability
gdinwiddie
Offline Offline
Send Email Send Email
 
Or maybe it's

dog.ExpressHappiness() {
sendEmotion(happiness);
}

and all the body parts are subscribed to the emotion broadcast.

- George

David Moye wrote:
> I assume it would be something like:
>
> dog.ExpressHappiness()
>
> which looks like:
>
> Body.WagTail()
>
> which looks like:
>
> Tail.Wag()
>
>
>
> David
>
>
>
>
>
> _____
>
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of jeffz_2002
> Sent: Tuesday, September 12, 2006 10:49 AM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Re: The Law of Demeter and Testability
>
>
>
> I'm hoping someone can clear up this nagging question ...
>
>> a good example:
>> dog.Body.Tail.Wag();
>> should really be:
>> dog.ExpressHappiness();
>
> I can understand that the first example is fragile in the face of
> code
> changes ... what I'm not clear on is how to get from
> dog.ExpressHappiness() to Tail.Wag().
>
> If the client used dog.Body.Tail.Wag(), then the client has too much
> knowledge about dog and its components ... bad. Any change to the
> dog
> classes could force client changes.
>
> But if we do dog.ExpressHappiness(), then wouldn't the code in dog be:
>
> // in Dog
> public void ExpressHappiness() throws NoTailException {
> this.Body.Tail.Wag();
> }
>
> and isn't this also a violation of Demeter, even if it's internal to
> Dog? If I wrote the dog class, and someone else wrote the Body
> class,
> would it be better to have the following in Body:
>
> // in Body
> public void ExpressHappiness() throws NoTailException {
> this.Tail.Wag();
> }
>
> Or, would you even go further ... after all, should Body /really/ be
> telling Tail how to go about expressing happiness?
>
> // in Body
> public void ExpressHappiness() throws NoTailException {
> this.Tail.ExpressHappiness();
> }
>
> // in Tail
> public void ExpressHappiness() throws NoTailException {
> this.Wag();
> }
>
> And then:
>
> // in Dog
> public void ExpressHappiness() throws NoTailException {
> this.Body.ExpressHappiness();
> }
>
> It seems a bit silly ... now every component in the chain has
> ExpressHappiness. I think I'm carrying the idea too far, but I'd
> like
> some feedback.
>
> Thanks for hearing me out.
>
> Jeff
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>


--
----------------------------------------------------------------------
* George Dinwiddie * gdinwiddie@...
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------




#122670 From: "Walter Prins" <wprins@...>
Date: Wed Sep 13, 2006 12:44 pm
Subject: Re: [XP] Re: The Law of Demeter and Testability
bytejuggler
Offline Offline
Send Email Send Email
 
Yep, that absolutely appeals to me.  (Though there's a little voice in my
head saying that I should ideally avoid building all the infrastructure
/levels of indirection for supporting that unless "pain"fully apparent
that's the best course of action...)

Walter

On 9/13/06, George Dinwiddie <lists@...> wrote:
>
> Or maybe it's
>
> dog.ExpressHappiness() {
> sendEmotion(happiness);
> }
>
> and all the body parts are subscribed to the emotion broadcast.
>
> - George
>
>


[Non-text portions of this message have been removed]




#122653 From: "Jay Flowers" <jay.flowers@...>
Date: Tue Sep 12, 2006 8:05 pm
Subject: Re: [XP] Re: The Law of Demeter and Testability
jfl0wers
Offline Offline
Send Email Send Email
 
This one looks best to me, and it does not violate the Law of Demeter.
It could even do things like lule tounge.

On 9/12/06, jeffz_2002 <jeffz_2002@...> wrote:
> // in Body
> public void ExpressHappiness() throws NoTailException {
> this.Tail.Wag();
> }

--
Jay Flowers
----------------------------------------------------------------------
http://jayflowers.com
---------------------------------------------------------------------



#122654 From: "Kay A. Pentecost" <kayp@...>
Date: Tue Sep 12, 2006 8:15 pm
Subject: RE: [XP] The Law of Demeter and Testability
tranzpuppy
Offline Offline
Send Email Send Email
 
Hi, Jay,

I found this interesting, thank you.

More below, keep reading.....

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jay Flowers
> Sent: Monday, September 11, 2006 4:01 PM
> To: testdrivendevelopment; Extreme Programming
> Subject: [XP] The Law of Demeter and Testability
>
> The Law of Demeter and Testability
> <http://jayflowers.com/WordPress/?p=78> Monday,
> September 11th, 2006
>
> The Law of Demeter, also know as the Principle of Least Knowledge, is
> important to controlling the type population of a test
<snip>
This
> smell has always
> reminded me of a violation of the Single Responsibility Principle.
> These symptoms indicate a violation of the Law of Demeter:
>
> - To Many Mock Objects
> - To Much Mock Setup
> - Mock Object Chaining

I don't know *why*, gramatically, but the first several times I read this I
thought you were saying that the "Law of Demeter" had too many mock objects,
etc.

It wasn't til I deliberately parsed it that I realized you were saying those
were "symptoms."

I wonder how you could re-write it to make it more obvious what you're
saying?

Kay


>
>





#122655 From: "Jay Flowers" <jay.flowers@...>
Date: Tue Sep 12, 2006 8:32 pm
Subject: Re: [XP] The Law of Demeter and Testability
jfl0wers
Offline Offline
Send Email Send Email
 
The first draft was something like:

I often read of other peoples troubles with mock objects. Some of the
issues are due to violations of the Law of Demeter.

- To Many Mock Objects
...

I thought that was too verbos, may the aditional context is needed.

On 9/12/06, Kay A. Pentecost <kayp@...> wrote:
> Hi, Jay,
>
> I found this interesting, thank you.
>
> More below, keep reading.....
>
> > -----Original Message-----
> > From: extremeprogramming@yahoogroups.com
> > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jay Flowers
> > Sent: Monday, September 11, 2006 4:01 PM
> > To: testdrivendevelopment; Extreme Programming
> > Subject: [XP] The Law of Demeter and Testability
> >
> > The Law of Demeter and Testability
> > <http://jayflowers.com/WordPress/?p=78> Monday,
> > September 11th, 2006
> >
> > The Law of Demeter, also know as the Principle of Least Knowledge, is
> > important to controlling the type population of a test
> <snip>
> This
> > smell has always
> > reminded me of a violation of the Single Responsibility Principle.
> > These symptoms indicate a violation of the Law of Demeter:
> >
> > - To Many Mock Objects
> > - To Much Mock Setup
> > - Mock Object Chaining
>
> I don't know *why*, gramatically, but the first several times I read this I
> thought you were saying that the "Law of Demeter" had too many mock objects,
> etc.
>
> It wasn't til I deliberately parsed it that I realized you were saying those
> were "symptoms."
>
> I wonder how you could re-write it to make it more obvious what you're
> saying?
>
> Kay
>
>
> >
> >
>
>
>
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>


--
Jay Flowers
----------------------------------------------------------------------
http://jayflowers.com
---------------------------------------------------------------------



#122656 From: "Kay A. Pentecost" <kayp@...>
Date: Tue Sep 12, 2006 8:54 pm
Subject: RE: [XP] The Law of Demeter and Testability
tranzpuppy
Offline Offline
Send Email Send Email
 
Hi, Jay,


> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jay Flowers
> Sent: Tuesday, September 12, 2006 4:33 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] The Law of Demeter and Testability
>
> The first draft was something like:
>
> I often read of other peoples troubles with mock objects. Some of the
> issues are due to violations of the Law of Demeter.
>
> - To Many Mock Objects
> ...
>
> I thought that was too verbos, may the aditional context is needed.

No, I don't think you need the extra words... the one you used what was
better than that. Maybe the "symptoms" word needs to be closer to the actual
symptoms...

"When you violate the law of Demeter, the symptoms are:
-- To Many Mock Objects

I was reading it as "the law of Demeter: to many mock objects..."

I'm sure there's a name for this kind of stylistic thing and I wish I knew
what it is!!

Does anyone know?

Kay


>
> On 9/12/06, Kay A. Pentecost <kayp@...> wrote:
> > Hi, Jay,
> >
> > I found this interesting, thank you.
> >
> > More below, keep reading.....
> >
> > > -----Original Message-----
> > > From: extremeprogramming@yahoogroups.com
> > > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> Jay Flowers
> > > Sent: Monday, September 11, 2006 4:01 PM
> > > To: testdrivendevelopment; Extreme Programming
> > > Subject: [XP] The Law of Demeter and Testability
> > >
> > > The Law of Demeter and Testability
> > > <http://jayflowers.com/WordPress/?p=78> Monday,
> > > September 11th, 2006
> > >
> > > The Law of Demeter, also know as the Principle of Least
> Knowledge, is
> > > important to controlling the type population of a test
> > <snip>
> > This
> > > smell has always
> > > reminded me of a violation of the Single Responsibility Principle.
> > > These symptoms indicate a violation of the Law of Demeter:
> > >
> > > - To Many Mock Objects
> > > - To Much Mock Setup
> > > - Mock Object Chaining
> >
> > I don't know *why*, gramatically, but the first several
> times I read this I
> > thought you were saying that the "Law of Demeter" had too
> many mock objects,
> > etc.
> >
> > It wasn't til I deliberately parsed it that I realized you
> were saying those
> > were "symptoms."
> >
> > I wonder how you could re-write it to make it more obvious
> what you're
> > saying?
> >
> > Kay
> >
> >
> > >
> > >
> >
> >
> >
> >
> > To Post a message, send it to: extremeprogramming@eGroups.com
> >
> > To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
> >
> > ad-free courtesy of objectmentor.com
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Jay Flowers
> ----------------------------------------------------------------------
> http://jayflowers.com
> ---------------------------------------------------------------------
>
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>





#122657 From: "Jay Flowers" <jay.flowers@...>
Date: Tue Sep 12, 2006 9:11 pm
Subject: Re: [XP] The Law of Demeter and Testability
jfl0wers
Offline Offline
Send Email Send Email
 
Kay,
Ahh! Now I see what you mean. Your right, it is similar to, the
imphisaas is on the wrong sylaable.

On 9/12/06, Kay A. Pentecost <kayp@...> wrote:
> Hi, Jay,
>
>
> > -----Original Message-----
> > From: extremeprogramming@yahoogroups.com
> > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jay Flowers
> > Sent: Tuesday, September 12, 2006 4:33 PM
> > To: extremeprogramming@yahoogroups.com
> > Subject: Re: [XP] The Law of Demeter and Testability
> >
> > The first draft was something like:
> >
> > I often read of other peoples troubles with mock objects. Some of the
> > issues are due to violations of the Law of Demeter.
> >
> > - To Many Mock Objects
> > ...
> >
> > I thought that was too verbos, may the aditional context is needed.
>
> No, I don't think you need the extra words... the one you used what was
> better than that. Maybe the "symptoms" word needs to be closer to the actual
> symptoms...
>
> "When you violate the law of Demeter, the symptoms are:
> -- To Many Mock Objects
>
> I was reading it as "the law of Demeter: to many mock objects..."
>
> I'm sure there's a name for this kind of stylistic thing and I wish I knew
> what it is!!
>
> Does anyone know?
>
> Kay
>
>
> >
> > On 9/12/06, Kay A. Pentecost <kayp@...> wrote:
> > > Hi, Jay,
> > >
> > > I found this interesting, thank you.
> > >
> > > More below, keep reading.....
> > >
> > > > -----Original Message-----
> > > > From: extremeprogramming@yahoogroups.com
> > > > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> > Jay Flowers
> > > > Sent: Monday, September 11, 2006 4:01 PM
> > > > To: testdrivendevelopment; Extreme Programming
> > > > Subject: [XP] The Law of Demeter and Testability
> > > >
> > > > The Law of Demeter and Testability
> > > > <http://jayflowers.com/WordPress/?p=78> Monday,
> > > > September 11th, 2006
> > > >
> > > > The Law of Demeter, also know as the Principle of Least
> > Knowledge, is
> > > > important to controlling the type population of a test
> > > <snip>
> > > This
> > > > smell has always
> > > > reminded me of a violation of the Single Responsibility Principle.
> > > > These symptoms indicate a violation of the Law of Demeter:
> > > >
> > > > - To Many Mock Objects
> > > > - To Much Mock Setup
> > > > - Mock Object Chaining
> > >
> > > I don't know *why*, gramatically, but the first several
> > times I read this I
> > > thought you were saying that the "Law of Demeter" had too
> > many mock objects,
> > > etc.
> > >
> > > It wasn't til I deliberately parsed it that I realized you
> > were saying those
> > > were "symptoms."
> > >
> > > I wonder how you could re-write it to make it more obvious
> > what you're
> > > saying?
> > >
> > > Kay
> > >
> > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > To Post a message, send it to: extremeprogramming@eGroups.com
> > >
> > > To Unsubscribe, send a blank message to:
> > extremeprogramming-unsubscribe@eGroups.com
> > >
> > > ad-free courtesy of objectmentor.com
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Jay Flowers
> > ----------------------------------------------------------------------
> > http://jayflowers.com
> > ---------------------------------------------------------------------
> >
> >
> > To Post a message, send it to: extremeprogramming@eGroups.com
> >
> > To Unsubscribe, send a blank message to:
> > extremeprogramming-unsubscribe@eGroups.com
> >
> > ad-free courtesy of objectmentor.com
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>


--
Jay Flowers
----------------------------------------------------------------------
http://jayflowers.com
---------------------------------------------------------------------



#122793 From: yahoogroups@...
Date: Thu Sep 21, 2006 12:31 am
Subject: Re: [XP] The Law of Demeter and Testability
jhrothjr
Offline Offline
Send Email Send Email
 
From: "Michael Feathers"
<mfeathers.at.mindspring.com@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Wednesday, September 20, 2006 2:17 PM
Subject: Re: [XP] The Law of Demeter and Testability


> Kevin Lawrence wrote:
>
>>On 9/19/06, Michael Feathers <mfeathers@...> wrote:
>>
>>
>>>very stable. In general, when the structure of data has meaning, LoD
>>>gets in the way; when you care more about behavior (and usually you
>>>can), LoD is the way to go.
>>>
>>>
>>>
>>
>>This resolves the Dog.Body.Tail.Wag() dilemma.
>>
>>Body.Tail in
>>
>>Dog.ExpressHappiness() {
>> Body.Tail.Wag();
>>}
>>
>>falls within the Feathers exclusion to LoD. Body is just a Tail container.
>>
>>
> I think it's trickier than that. To me, the question is whether anyone
> needs to know that a body has a tail. Does the program need to know?

It's a bit trickier. There might be valid reasons for someone
outside to know if the body has a tail, but there might be no
reason to know that ExpressHappiness involves the tail.

For example, if we want to substitute a cat.

To make this a bit more concrete, what if we were writing
an IF (interactive fiction, also known as text adventure) and
wanted both an expressHappiness action and some action if
we accidentally stepped on the animal's tail.

The latter case has to expose the tail, because there's probably
a verb that knows about stepping on a tail. The first doesn't,
because it's probably generic.

John Roth

> Michael Feathers
> www.objectmentor.com




#123982 From: yahoogroups@...
Date: Wed Nov 15, 2006 10:33 pm
Subject: Re: [XP] The Law of Demeter and Testability
jhrothjr
Offline Offline
Send Email Send Email
 
From: "Paul Campbell"
<yahoo.at.objectvision.co.uk@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Wednesday, November 15, 2006 11:04 AM
Subject: Re: [XP] The Law of Demeter and Testability


--- In extremeprogramming@yahoogroups.com, Brad Appleton
<Brad.Appleton@...> wrote:
>
> Paul Campbell wrote:
> > Brad Appleton wrote:
> > > When a method-call returns a subobject of its containing
object, then
> > > consider that invocation to be a violation of LOD *only* *if* the
> > > containing object is supposed to encapsulate behavior
concerning its
> > > subobjects.
> >
> > I believe there is another case where it is not a violation: where the
> > behavioural sematics of the relationship between the parent and the
> > child object map exactly onto the default semantics of the language
> > implementing the relationship. Here demeterising the relationship is
> > wholely redundent and indeed actually damaging.
> >
> > There are countless examples of domain concepts where "X contains n *
> > Y" and it is right and proper IMO to use the native OO structural
> > relationship to express and expose this as a directly navigable object
> > reference.
>
> I think the case you mention above qualifies as an instance of what I
> described. When the containment of the subobject is not a "secret" that
> needs to be encapsulated, then it is simply a proper part of the
> "interface", and it is not behavior that is being encapsulated, but
> rather the implementation of the containment/collection (structure).
>

So is Demeter then merely restating the need not to expose
implementation objects ?. I thought it went beyond that to dissalow
navigating from one visible, and otherwise correctly encapsulated,
object to another.

To clarify: encapsulation says that a public interface should not be
able to place an object in an invalid state. Demeter OTOH, as I
understand it, goes beyond this to say that even if a reference
exposed by an object cannot be used to break its invarients, it is
still under certain cirsumstances bad style to expose that reference ?.

Paul C.

[Response]

As far as I can tell, the issue isn't encapsulation per se, it's
coupling. The farther in you dig, the more knowledge that
particular statement has about the structure of the objects
concerned, and the higher the coupling.

That said, there certainly are times when the approprate
domain structure really is a network of objects with a known
set of semantics, but even then I think it would be best to
hide that from the rest of the system, and provide useful
search and manipulate methods on a gateway object.

John Roth








#122748 From: John Carter <john.carter@...>
Date: Mon Sep 18, 2006 11:38 pm
Subject: Re: [XP] The Law of Demeter and Testability
refactored
Offline Offline
Send Email Send Email
 
On Mon, 11 Sep 2006, Jay Flowers wrote:

> The Law of Demeter and Testability
> <http://jayflowers.com/WordPress/?p=78> Monday,
> September 11th, 2006

Thank you! Excellent Article!

I have forwarded around my colleagues begging them to read it.

In someways I see LoD as the "super principle".

LoD is very very subtle, and it's validity is not transparently obvious.

Yet the result of applying many of the other design principles tends to
look as if someone has gone around applying LoD.

(Ps: The example I use to illustrate LoD most graphically is that of a
newspaper vendor reaching into your pants coin pocket, extracting his
fee and putting the change back.)


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@...
New Zealand

"We have more to fear from
The Bungling of the Incompetent
Than from the Machinations of the Wicked." (source unknown)



#122750 From: "Jay Flowers" <jay.flowers@...>
Date: Tue Sep 19, 2006 12:27 am
Subject: Re: [XP] The Law of Demeter and Testability
jfl0wers
Offline Offline
Send Email Send Email
 
John,
Your welcome. Thank you! I hope I can do even better with rest of the
series.

I like that example very much. It definitely makes it feel like a
violation.

On 9/18/06, John Carter <john.carter@...> wrote:
>
> On Mon, 11 Sep 2006, Jay Flowers wrote:
>
> > The Law of Demeter and Testability
> > <http://jayflowers.com/WordPress/?p=78> Monday,
> > September 11th, 2006
>
> Thank you! Excellent Article!
>
> I have forwarded around my colleagues begging them to read it.
>
> In someways I see LoD as the "super principle".
>
> LoD is very very subtle, and it's validity is not transparently obvious.
>
> Yet the result of applying many of the other design principles tends to
> look as if someone has gone around applying LoD.
>
> (Ps: The example I use to illustrate LoD most graphically is that of a
> newspaper vendor reaching into your pants coin pocket, extracting his
> fee and putting the change back.)
>
>
> John Carter Phone : (64)(3) 358 6639
> Tait Electronics Fax : (64)(3) 359 4632
> PO Box 1645 Christchurch Email : john.carter@...
> New Zealand
>
> "We have more to fear from
> The Bungling of the Incompetent
> Than from the Machinations of the Wicked." (source unknown)
>
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>


--
Jay Flowers
----------------------------------------------------------------------
http://jayflowers.com
---------------------------------------------------------------------


[Non-text portions of this message have been removed]




#122767 From: Michael Feathers <mfeathers@...>
Date: Tue Sep 19, 2006 7:02 pm
Subject: Re: [XP] The Law of Demeter and Testability
mfeathers256
Offline Offline
Send Email Send Email
 
John Carter wrote:

>On Mon, 11 Sep 2006, Jay Flowers wrote:
>
>
>
>>The Law of Demeter and Testability
>><http://jayflowers.com/WordPress/?p=78> Monday,
>>September 11th, 2006
>>
>>
>
>Thank you! Excellent Article!
>
>I have forwarded around my colleagues begging them to read it.
>
>In someways I see LoD as the "super principle".
>
>LoD is very very subtle, and it's validity is not transparently obvious.
>
>Yet the result of applying many of the other design principles tends to
>look as if someone has gone around applying LoD.
>
>
It's a great article, but the thing to remember about LoD is that it is
not iron-clad. There are cases where you're better off not having
demetered code. The classic example is the Excel Object model. You get
the workbook from the application and the worksheet from the workbook,
and drill down through ranges to cells. It works because the model is
very stable. In general, when the structure of data has meaning, LoD
gets in the way; when you care more about behavior (and usually you
can), LoD is the way to go.


Michael Feathers
www.objectmentor.com



#122778 From: Ron Jeffries <ronjeffries@...>
Date: Tue Sep 19, 2006 11:39 pm
Subject: Re: [XP] The Law of Demeter and Testability
RonaldEJeffries
Offline Offline
Send Email Send Email
 
Hello Michael, thanks for your note. On Tuesday, September 19, 2006,
at 3:02:27 PM, you wrote:

> It's a great article, but the thing to remember about LoD is that it is
> not iron-clad. There are cases where you're better off not having
> demetered code. The classic example is the Excel Object model. You get
> the workbook from the application and the worksheet from the workbook,
> and drill down through ranges to cells. It works because the model is
> very stable. In general, when the structure of data has meaning, LoD
> gets in the way; when you care more about behavior (and usually you
> can), LoD is the way to go.

Yes ... the observation about structure is a good one. If you think
of what you'd have to do, otherwise, with the Excel model, you'd
have to make each call to Excel, parameterized with workbook name,
worksheet name, maybe range, then cell. Pulling the innards out
amounts to an addressing prefix, or stepping down through a
hierarchy.

Mostly, though, I'd say LoD is the way to bet.

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? -- E M Forster




#122786 From: Willem Bogaerts <w-p@...>
Date: Wed Sep 20, 2006 10:31 am
Subject: Re: [XP] The Law of Demeter and Testability
toetah2000
Offline Offline
Send Email Send Email
 
There is a "counterforce" that sometimes causes me to put the Law of
Demeter aside: the notion of Design by Contract.

In my current project, I have a situation that a user must be logged in
to a web system, always. So I have a ForceLogin() method on the
Application object. It is the responsibility of the Application object
to see to it that someone is logged in (if nobody is logged in, it
causes a login form to be shown). But the application class calls
$this->Backend()->Users()->Login(...) , as it is the responsibility of
the Users colection to handle the login action. According to the Law of
Demeter, I should also have some login method on the Backend object, but
that does make no sense in terms of responsibility. The sole
responsibility of the Backend class is to (lazily) provide access to the
data structure.

>> not iron-clad. There are cases where you're better off not having
>> demetered code. The classic example is the Excel Object model. You get
>> the workbook from the application and the worksheet from the workbook,
>> and drill down through ranges to cells. It works because the model is
>> very stable. In general, when the structure of data has meaning, LoD
>> gets in the way; when you care more about behavior (and usually you
>> can), LoD is the way to go.

That reminds me of the DAO object model (MS-Access), where
DBEngine(0)(0) is the first database (and is often abused as a way to
find the current database). It is not a method, but some shorthand that
involves default methods (in full, it was written as
DBEngine.Workspaces.Item(0).Databases.Item(0) ). There was also a
CurrentDB method on DBEngine, but not a CurrentWorkspace method.
So the default methods can make it look like there is a navigation
method on the package root.

> Yes ... the observation about structure is a good one. If you think
> of what you'd have to do, otherwise, with the Excel model, you'd
> have to make each call to Excel, parameterized with workbook name,
> worksheet name, maybe range, then cell. Pulling the innards out
> amounts to an addressing prefix, or stepping down through a
> hierarchy.
>
> Mostly, though, I'd say LoD is the way to bet.

I do agree here. If I break the Law of Demeter, I only do so when I have
a good reason to. In most cases, that reason is the responsibility of
the classes involved.

Best regards,
Willem Bogaerts



#122787 From: Paul <paultsai@...>
Date: Wed Sep 20, 2006 3:48 pm
Subject: Re: [XP] The Law of Demeter and Testability
altacus
Offline Offline
Send Email Send Email
 
Hey I just wanted to throw something out there, I don't believe it breaks
demeter. Let me know what you guys think.

Public Dog {

public event void ExpressHappiness;

public Dog()
{
ExpressHappiness += EventHandler(Emote);
}

public void Emote (object sender, EventArgs e){
try {Emotion feeling = (Emotion)sender;}
catch{throw new Exception ("Trying to emote a non-emotion!");}
Body.Express(feeling);
Tail.Express(feeling);
Ears.Express(feeling);
}
}

--
Paul
Email - paultsai@...


[Non-text portions of this message have been removed]




#122788 From: Michael Feathers <mfeathers@...>
Date: Wed Sep 20, 2006 6:03 pm
Subject: Re: [XP] The Law of Demeter and Testability
mfeathers256
Offline Offline
Send Email Send Email
 
Willem Bogaerts wrote:

>There is a "counterforce" that sometimes causes me to put the Law of
>Demeter aside: the notion of Design by Contract.
>
>In my current project, I have a situation that a user must be logged in
>to a web system, always. So I have a ForceLogin() method on the
>Application object. It is the responsibility of the Application object
>to see to it that someone is logged in (if nobody is logged in, it
>causes a login form to be shown). But the application class calls
>$this->Backend()->Users()->Login(...) , as it is the responsibility of
>the Users colection to handle the login action. According to the Law of
>Demeter, I should also have some login method on the Backend object, but
>that does make no sense in terms of responsibility. The sole
>responsibility of the Backend class is to (lazily) provide access to the
>data structure.
>
I'm not saying it's an answer here, but sometimes I get mileage out of
rethinking the primary responsibility of a class. Backend provides
access, but what happens with that access? If you put ForceLogin on
Backend, would you be tempted to change Backend's name?

Michael Feathers
www.objectmentor.com




#122790 From: Willem Bogaerts <w-p@...>
Date: Wed Sep 20, 2006 6:49 pm
Subject: Re: [XP] The Law of Demeter and Testability
toetah2000
Offline Offline
Send Email Send Email
 
>> In my current project, I have a situation that a user must be logged in
>> to a web system, always. So I have a ForceLogin() method on the
>> Application object. It is the responsibility of the Application object
>> to see to it that someone is logged in (if nobody is logged in, it
>> causes a login form to be shown). But the application class calls
>> $this->Backend()->Users()->Login(...) , as it is the responsibility of
>> the Users colection to handle the login action. According to the Law of
>> Demeter, I should also have some login method on the Backend object, but
>> that does make no sense in terms of responsibility. The sole
>> responsibility of the Backend class is to (lazily) provide access to the
>> data structure.
>>
> I'm not saying it's an answer here, but sometimes I get mileage out of
> rethinking the primary responsibility of a class. Backend provides
> access, but what happens with that access? If you put ForceLogin on
> Backend, would you be tempted to change Backend's name?

In this case, no. Backend manages (and hides) three kinds of storage.
Its purpose is to offer the rest of the code a central point of access
to the "table wrapper" collections and the DataLines that are attached
to them. You could see the Backend as a switch board or a telephone
operator. It is backend's job to connect to, but not interfere with the
data.
A ForceLogin on the backend would suggest you'd have to log in in the
storage system itself. While this is true, this login is already taken
care in Backend's constructor. The existing ForceLogin on the
application level uses this connected data structure to provide a login
to the application, not to its storage.

If I put the ForceLogin on the Backend object, I'd move it immediately.
Not because of the name, but because it does not fit in a switchboard.
Or I would move the collections. Either way, I'd create a new
Application class or a new Backend class.

Best regards,
Willem Bogaerts



#122914 From: "J. B. Rainsberger" <jbrains762@...>
Date: Wed Sep 27, 2006 5:57 pm
Subject: Re: [XP] The Law of Demeter and Testability
nails762
Offline Offline
Send Email Send Email
 
Ron Jeffries wrote:
>
>
> Hello Michael, thanks for your note. On Tuesday, September 19, 2006,
> at 3:02:27 PM, you wrote:
>
> > It's a great article, but the thing to remember about LoD is that it is
> > not iron-clad. There are cases where you're better off not having
> > demetered code. The classic example is the Excel Object model. You get
> > the workbook from the application and the worksheet from the workbook,
> > and drill down through ranges to cells. It works because the model is
> > very stable. In general, when the structure of data has meaning, LoD
> > gets in the way; when you care more about behavior (and usually you
> > can), LoD is the way to go.
>
> Yes ... the observation about structure is a good one. If you think
> of what you'd have to do, otherwise, with the Excel model, you'd
> have to make each call to Excel, parameterized with workbook name,
> worksheet name, maybe range, then cell. Pulling the innards out
> amounts to an addressing prefix, or stepping down through a
> hierarchy.
>
> Mostly, though, I'd say LoD is the way to bet.

I think of it this way: any algorithm should /either/ talk to its direct
neighbors /or/ reach into the belly of the beast, but not both. Said
differently, don't ask your neighbor to do something, then ask him for
/his/ neighbor and ask /him/ to do something, then ask #2 for neighbor
#3.... that kind of algorithm is tough to test.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice




#123933 From: "Paul Campbell" <yahoo@...>
Date: Mon Nov 13, 2006 10:39 am
Subject: Re: The Law of Demeter and Testability
pncampbell99
Offline Offline
Send Email Send Email
 
--- In extremeprogramming@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:
>
> Hello Michael, thanks for your note. On Tuesday, September 19, 2006,
> at 3:02:27 PM, you wrote:
>
> > It's a great article, but the thing to remember about LoD is that
it is
> > not iron-clad. There are cases where you're better off not having
> > demetered code. The classic example is the Excel Object model.
You get
> > the workbook from the application and the worksheet from the workbook,
> > and drill down through ranges to cells. It works because the model is
> > very stable. In general, when the structure of data has meaning, LoD
> > gets in the way; when you care more about behavior (and usually you
> > can), LoD is the way to go.
>
> Yes ... the observation about structure is a good one.

Sorry for
resurecting an old topic but Ive been off line for a while ...

I dont believe there is a meaningful distiction between structure and
behviour in domain level classes: the structure is an integral part of
the behaviour. Where struture directly conveys domain level concepts
then facading it away is counter productive and leads to more rigid code.

> Mostly, though, I'd say LoD is the way to bet.

I agree, but only because the majority of classes in most applications
are not directly expressing domain concepts - its just that the ones
that are, are the most important ones, and the ones where demeter does
disproportionate damage when missaplied.

Paul.






#123935 From: Ron Jeffries <ronjeffries@...>
Date: Mon Nov 13, 2006 11:16 am
Subject: Re: [XP] Re: The Law of Demeter and Testability
RonaldEJeffries
Offline Offline
Send Email Send Email
 
Hello, Paul. I don't understand your points. I'll say more near them
... On Monday, November 13, 2006, at 5:39:24 AM, you wrote:

> --- In extremeprogramming@yahoogroups.com, Ron Jeffries
> <ronjeffries@...> wrote:
>>
>> Hello Michael, thanks for your note. On Tuesday, September 19, 2006,
>> at 3:02:27 PM, you wrote:

>>> It's a great article, but the thing to remember about LoD is
>>> that it is not iron-clad. There are cases where you're better
>>> off not having demetered code. The classic example is the Excel
>>> Object model.

>>> You get the workbook from the application and the worksheet from
>>> the workbook, and drill down through ranges to cells. It works
>>> because the model is very stable. In general, when the structure
>>> of data has meaning, LoD gets in the way; when you care more
>>> about behavior (and usually you can), LoD is the way to go.
>>
>> Yes ... the observation about structure is a good one.

> Sorry for resurecting an old topic but Ive been off line for a
> while ...

> I dont believe there is a meaningful distiction between structure and
> behviour in domain level classes: the structure is an integral part of
> the behaviour. Where struture directly conveys domain level concepts
> then facading it away is counter productive and leads to more rigid code.

I'm not clear which side you're coming down on. I take it that you
would agree with Michael's example that with a spreadsheet,
demetering your way down through it is righteous?

But outside that very structured situation, I'm not sure what kind
of structure, conveying domain level concepts, you might be talking
about.

If airlines forwarded voicemail to people on their airplanes, should
they not send the message to the flight, not the seat?

If we want to give a raise to an employee, should we have to drill
down through multiple layers of management to do it?

If those examples aren't germane ... what examples would make your
point?

>> Mostly, though, I'd say LoD is the way to bet.

> I agree, but only because the majority of classes in most applications
> are not directly expressing domain concepts - its just that the ones
> that are, are the most important ones, and the ones where demeter does
> disproportionate damage when missaplied.

I have no mental hooks to hang this notion on. I don't recall ever
regretting following LoD. Examples, please?

Ron Jeffries
www.XProgramming.com
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
-- after Mark Vaughn, Autoweek.


#123939 From: "Paul Campbell" <yahoo@...>
Date: Mon Nov 13, 2006 12:18 pm
Subject: [XP] Re: The Law of Demeter and Testability
pncampbell99
Offline Offline
Send Email Send Email
 
--- In extremeprogramming@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:


> If we want to give a raise to an employee, should we have to drill
> down through multiple layers of management to do it?

Of course an employee would be directly resolvable via a repository in
this example. But for any business logic where an employees department
is pertinent then direct exposure of a key relatioship as an object
reference would probably be apppropriate. For example if I wanted to
move an employee from one deparment to another then I get most of that
behaviour for "free" if I model deparment-employee as an explicit OO
containment relationship.

Of course its possible that the relationship between employee and
department is too complex to model as OO containment , and thats fine
because in that case we dont have that relationship *at all* in our
domain level classes: its not the correct solution to have that
relationship at one level and then facade it away at a higher level (IMO).

Again IME the urge to demeterise domain classes stems from not
correctly apportioning object location/addressing responsiblity
between repositories (usually plain old "queries") on the one hand and
direct reference navigation on the other.

Paul C.








#123941 From: Ron Jeffries <ronjeffries@...>
Date: Mon Nov 13, 2006 1:34 pm
Subject: Re: [XP] Re: The Law of Demeter and Testability
RonaldEJeffries
Offline Offline
Send Email Send Email
 
Hello, Paul. I'm sorry ... On Monday, November 13, 2006, at 7:18:28
AM, you wrote:

>> If we want to give a raise to an employee, should we have to drill
>> down through multiple layers of management to do it?

> Of course an employee would be directly resolvable via a repository in
> this example. But for any business logic where an employees department
> is pertinent then direct exposure of a key relatioship as an object
> reference would probably be apppropriate. For example if I wanted to
> move an employee from one deparment to another then I get most of that
> behaviour for "free" if I model deparment-employee as an explicit OO
> containment relationship.

> Of course its possible that the relationship between employee and
> department is too complex to model as OO containment , and thats fine
> because in that case we dont have that relationship *at all* in our
> domain level classes: its not the correct solution to have that
> relationship at one level and then facade it away at a higher level (IMO).

> Again IME the urge to demeterise domain classes stems from not
> correctly apportioning object location/addressing responsiblity
> between repositories (usually plain old "queries") on the one hand and
> direct reference navigation on the other.

I'm still not getting what you're at. It's too abstract for me to be
sure that I'm assigning the same meanings to the words as you are,
and when I do assign meanings to the words, I don't get statements
that are obviously true.

Ron Jeffries
www.XProgramming.com
What is your dream? And knowing this, what have you
done to work towards realizing it today? -- Les Brown




 
First  | < Prev  |  Last 
Advanced
Add to My Yahoo!      XML What's This?

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help