[fxn]

He does not say it is bad per se.

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".

[gary_bernhardt]

DHH quote: "I think the Law of Demeter is shit and never follow it."

(from http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-...)

[fxn]

Because he judges a series of dots by themselves, not because any law mandantes anything. He gives a shit about these grandiose names, show me the code and let's discus on that.

[gary_bernhardt]

I was responding to your claim that "He does not say it is bad per se." Calling it "shit" seems like "[saying] it is bad".

[fxn]

If you present a code with ten dots, he will probably say it is bad code. But he won't invoke law of demeter. That's the point I think.

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.

[derefr]

> When people invoke SRP a priori they sometimes end up with one class == one method in a theoretical a priori way.

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.