Moved From
LawOfDemeter.
I contended that law of demeter is badly formulated heuristic that at best (when it applies , that is, cause it's not always a valid law) is a particular case of
InformationHiding. Therefore it is both unnecessary and confusing. --
AnonymousCoward
Can you elaborate? --
GuillermoSchwarz
Maybe we should all give up on
LawOfDemeter and decree that it is a badly formulated heuristic that raises a lot of problems, including those discussed on this page, and in the end, at a closer look we may discover that it is a squared wheel reinvention of
DavidParnas' principle of
InformationHiding in the particular case of
ObjectOrientedProgramming. However the particular case represented by
LawOfDemeter severely restricts the generality of
InformationHiding and may provide false leads to OO practitioners. In other words, if one design is "good" or even "optimal" under the
InformationHiding criteria, we no longer need to worry about
LawOfDemeter, but the reverse is generally not true.
I see the LawOfDemeter as something that, if followed, enforces Parnas' principle of InformationHiding.
In support of this thesis I bring
KarlLieberherr's updated general formulation of the
LawOfDemeter http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html where he says:
- Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
But in essence this is exactly the same thing as formulated by
DavidParnas seminal paper "On the Criteria to Be Used in Decomposing Systems into Modules" which dates from 1972. --
CostinCozianu
It's interesting to follow this discussion because most people seem to be
missing an important point. The Law of Demeter is not a pattern since
it does not have a context. In all probability, the Law of Demeter could
be a useful pattern if placed into a context in which it does resolve
the forces of that context and then there will be no need to discuss
whether the Law is
true or not. --
MichaelDillon
The above is actually just a common misunderstanding because most folks aren't given the full story when they learn about the LawOfDemeter. While it's certainly not a pattern, nor should it be IMHO, it really does have a context, albeit a very broad one.
[Moved from
LawOfDemeter]
This has been moved here because Demeter tries to establish a relation about objects created and used within a method or function, while Parnas' InformationHiding has to do with modules, or what we would call today JavaPackages.
Modules are not packages, nor the other way around. Maybe we should expand on this here on wiki, but please refer to
SoftwareFundamentals or to online available publications by
DavidParnas with regards to modules.