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]

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

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]

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]

> 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

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

--- 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.

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]

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

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

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]

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

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

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





>

>

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

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

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

>

>

>

>

>

>

>

>

>

>

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

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

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

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

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)

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]

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

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

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

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]

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

>> 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

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

--- 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.

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.

--- 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.

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