3 ms·

The Law of Demeter is more fine-grained, though. If I write classes A, B and C, I'm not supposed to call A.getB().getC().doThings(), even if I'm the author of A

The Law of Demeter is more fine-grained, though. If I write classes A, B and C, I'm not supposed to call A.getB().getC().doThings(), even if I'm the author of A, B and C. So the Law of Demeter is potentially more fine-grained than anything you might infer based on organizational structure.

TeMPOraL 7y ago
That granularity makes it pretty much ridiculous. What if A's main purpose is to give you Bs, and B's main purpose is to give you Cs that do things? (I'm probably rehashing some trivial objection, but throughout all my years doing OOP, that one "law" never made much sense to me.)
- hyperpape 7y ago
  I think it's one of those rules that is referencing a real phenomenon that is too hard to state precisely. If B is a factory class, it's clearly not applicable, but there are other cases where it's bad.
- stcredzero 7y ago
  That granularity makes it pretty much ridiculous. If you do lots of refactoring, it's great. It could well be the case that most people don't refactor as fast as people did with the Refactoring Browser in Smalltalk. No refactoring was enabled, unless it was guaranteed to be correct, and you could fire them off almost as fast as you could select the right-click menu. On top of that, you had unlimited undo/redo on the refactorings, and on top of that, there was always the Smalltalk Change Log as an ultimate safety net. So when I was in the zone, I would sometimes get an idea, fire off the prototype of a major refactoring as a dozen rapid-fire operations, look at the result, then back it out if I didn't like it. Refactoring was more exploratory in those days. The Law of Demeter pre-dates those Refactoring Browser days. Basically, it dates from a time before the Refactoring Browser, when people wished they could refactor that fast, but still used the practice heavily. If ease of refactoring isn't that high a priority to you, the cost/benefit of warping your practices around refactoring might not pan out. "Simple as that," to quote the recently departed.
- slowmovintarget 7y ago
  The point of the law is that if your conditions are true, you are designing the code incorrectly. The point is to avoid making what should be transitive dependencies into direct dependencies. The reason for this is that you may terminate transitive dependencies with interfaces, but only if you don't write train wrecks like a.getB().getC().doTheThing(). You should, compose the interfaces so that you are expressing a.doTheThing(). But sometimes ya gotta do what ya gotta do, which is why this was later comically referred to as "The Jolly Good Principle of Demeter" instead of "Law".
  - wongarsu 7y ago
    >The Jolly Good Principle of Demeter Or as Jesus said: The Law of Demeter was made for man, not man for the Law of Demeter (Mark 2:27).

TeMPOraL 7y ago

That granularity makes it pretty much ridiculous. What if A's main purpose is to give you Bs, and B's main purpose is to give you Cs that do things? (I'm probably rehashing some trivial objection, but throughout all my years doing OOP, that one "law" never made much sense to me.)

hyperpape 7y ago
I think it's one of those rules that is referencing a real phenomenon that is too hard to state precisely. If B is a factory class, it's clearly not applicable, but there are other cases where it's bad.
stcredzero 7y ago
That granularity makes it pretty much ridiculous. If you do lots of refactoring, it's great. It could well be the case that most people don't refactor as fast as people did with the Refactoring Browser in Smalltalk. No refactoring was enabled, unless it was guaranteed to be correct, and you could fire them off almost as fast as you could select the right-click menu. On top of that, you had unlimited undo/redo on the refactorings, and on top of that, there was always the Smalltalk Change Log as an ultimate safety net. So when I was in the zone, I would sometimes get an idea, fire off the prototype of a major refactoring as a dozen rapid-fire operations, look at the result, then back it out if I didn't like it. Refactoring was more exploratory in those days. The Law of Demeter pre-dates those Refactoring Browser days. Basically, it dates from a time before the Refactoring Browser, when people wished they could refactor that fast, but still used the practice heavily. If ease of refactoring isn't that high a priority to you, the cost/benefit of warping your practices around refactoring might not pan out. "Simple as that," to quote the recently departed.
slowmovintarget 7y ago
The point of the law is that if your conditions are true, you are designing the code incorrectly. The point is to avoid making what should be transitive dependencies into direct dependencies. The reason for this is that you may terminate transitive dependencies with interfaces, but only if you don't write train wrecks like a.getB().getC().doTheThing(). You should, compose the interfaces so that you are expressing a.doTheThing(). But sometimes ya gotta do what ya gotta do, which is why this was later comically referred to as "The Jolly Good Principle of Demeter" instead of "Law".
- wongarsu 7y ago
  >The Jolly Good Principle of Demeter Or as Jesus said: The Law of Demeter was made for man, not man for the Law of Demeter (Mark 2:27).