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?
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 JavaPackage?s.
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.