in reply to Definition of Law of Demeter
in thread Are lvalue methods (as properties) a good idea?
Let's say object A has a method foo() that does something useful. Object a (instance-of class A) has-an object b that implements the useful thing.
So the call chain is a->b->foo(). But that exposes the fact that a has-a b, when in fact that information could be private to class A. According to the LoD, the call chain would be a->foo(), and that foo() would be implemented as b->foo().
Taken to an extreme, this is the “bloated middlemen classes full of forwarding methods.” that Aristotle talks about in Re^3: Are lvalue methods (as properties) a good idea?. If large parts of the interface of B is duplicated in A, what's the point? Isn't A and B pretty tightly coupled anyway?
On the other hand... What if the call chain is a->b->c->d->foo(), and you type this monster at 108 different places in your program? Wouldn't it be a bit nicer to type a->foo() and encapsulate the knowledge of b->c->d->foo() so it doesn't break at 108 different places if any of b, c, or d changes?
This is why the LoD shouldn't be a "law" to be followed at all times, but a rather a guideline. Or as the Pragmatic guys phrased it in an article I read somewhere: The Pretty Good Idea of Demeter.
(hey, I just found it. The Art of Enbugging. It's really good and, of course, explains it a lot better than I can).
IMHO,
/J
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: The Pretty Good Idea of Demeter (Was: Definition of Law of Demeter)
by fergal (Chaplain) on Jan 16, 2005 at 13:07 UTC | |
by Aristotle (Chancellor) on Jan 17, 2005 at 22:30 UTC | |
by jplindstrom (Monsignor) on Jan 16, 2005 at 14:52 UTC |