Does anybody here need analysis for Law of Demeter (LoD) violations for Nerpa?
Personally I think it is almost useless in its direct form. Here is why.
Formally, the Law of Demeter for functions requires that any method M of
an object O may only invoke the methods of the following kinds of objects:
any objects it creates/instantiates
its direct component objects
1. It is actually pretty complex. It requires tracking live instances of
variables through the flow graph, including aliasing and other compiler-level
Not that it is impossible, but it should have good argumentation to start
implementing it and tackle complexity.
2. It requires external knowledge about code to avoid false positives. For
example, factory methods should be treated as "any objects it creates/instantiates"
rule for LoD, but formally it is "object returned by another method". Singleton.Instance
is a simple example of this. But there can be much more complex cases.
What should analysis algorithm think about the following case?
void foo(ISolution solution)
MySolutionComponent c = (MySolutionComponent)solution.GetComponent(typeof(MySolutionComponent));
If is treated as factory method, then it falls into "objects it creates/instantiates"
and is valid from the LoD point of view. If is an ordinary method
call, than is violation of rules.
3. Its definition is *intentionally left vague so that it can be adapted
to particular circumstances". Here are some definitions:
I. Each unit should only talk to its friends; Don't talk to strangers. There
are several definitions about who is considered "a friend". I've found the
following to be the most specific:
1. A parameter of the method, including the enclosing object (this); For
pragmatic reasons: a global object;
2. An immediate part object (computed or stored)
attributes of the enclosing object;
3. An object created within the method.
Note, the difference from wikipedia definition - it includes collections
and global objects. #3 should be extended to allow factory methods.
II. Each unit should have only limited knowledge about other units: only
units "closely" related to the current unit.
unit = METHOD
closely related =
1. methods of class of this of METHOD
2. methods of immediate part classes
3. methods of classes of objects that are created in METHOD.
These two definitions (I & II) seems similar, but they are different. The
first one specifies objects, while the second specifies types. For example,
Bar bar = _field.GetExternalBar();
By the first set of rules is invalid, while for the second set of rules
is valid. And both these formulations are from the same source! If one
looks at web, he'll find more different formulations, which treat various
However, all of these definitions of LoD are more specific cases of the Low
Coupling Principle. May be we just select some more simple and efficient
coupling analysis system and leave LoD to researchers and theory builders? :)