Reducing the knowledge of internal structures is what the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter) is about. Usually good practice.
- http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-...
What he criticizes is using any of these "laws" and "principles" as if they were truths, as if the argument was based on an axiom or had the strength of science.
They are "inferred" from experience statistically speaking, but in each individual case you need to gauge and check yourself whether those three dots make or not make sense.
It is your judgement in particular code that matters, not the a priori invocation of any "law" or "principle".
(from http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-...)
Is like invoking SRP. Fuck that. When you are experienced, you develop a sense on delineating responsabilities in a way that fits your application.
I am not David of course, but I have participated in some discussions with him, and we think very much alike on these topics, I think what I say above is right.
Going to switch to myself now: When people invoke SRP a priori they sometimes end up with one class == one method in a theoretical a priori way.
I don't think that works. It goes in the reverse direction. SRP is inferred, it emerges, it is not applied as if it was a logical proposition.
That's... not really what SRP means. This (http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsib...) was on HN just a bit ago--Mr. Martin being the guy who gave us the term. Let me quote the essential bit:
> And this gets to the crux of the Single Responsibility Principle. This principle is about people.
> When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function. You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.
I've been somewhat suspicious of the law of demeter (not firmly on one side or the other), but this article actually helped me see the value of it.
It's not that "you can't do this because it violates the law of demeter." That's a ridiculous cargo cult way to use software design principles (which, yeah, is quite common). Rather, it's, the law of demeter is good because it prevents THIS stuff, which you don't want.
Like, okay, DHH thinks the law of demeter is useless, but he hates things that... the law of demeter is meant to and helps prevent.