There is (immutable) data and there are modules. Encapsulation / Demeter make it hard to work with data. OTOH, Encapsulation / Demeter are good for modules.
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".
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.
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.
> 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.
Ah, but I think OP is a pretty good explanation of _why_ the Law of Demeter is actually good, although it doesn't use that phrase.
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.
I agree with you that the post is a great explanation of why Demeter is good. All I mean to say is "this is just Demeter" is not a refutation of "I think the Law of Demeter is shit and never follow it." (See my links in your sibling, that's a quote.)
Well, one thing I learned from all this recent TDD related discussion is that almost nobody is aware of this book [1] and the entire school of TDD it spawned.
That sounds vaguely similar to "Functional Core, Imperative Shell". I merge state management and coordination (together, the shell) so that the logic (the core) can be composed of pure functions without coordination overhead. So far I've done very little testing of the imperative shell.
This is a great book. Although I must admit it kind of "washed over me" a bit too much. Perhaps it was just the java.. I think I need to re-read it to be able to synthesize the ideas in it, and connect the high-level ideas to the examples later in the book enough to be able to get the same results in my own work.
Yes, we should avoid mocks of mocks. But building small pieces of code that have little knowledge of their surroundings, and testing them independently, is no panacea.
You can see this problem in any Java Enterprise shop that has code coverage as a religion: To make it possible to cover all that code (including all the boilerplate caused by the technologies selected), then we end up with a billion little classes that are managed by some kind of dependency injection system. Hundreds of thousands of lines of Spring XML configuration files, or their equivalent in annotations. Every piece is tested, but are all the pieces tested together, automatically? We quickly get into extremely large and expensive automation suites, or a whole lot of things that aren't really tested regularly, making all those unit tests a lot less valuable.
We can't wish complexity away: Make every unit too small, and the management of the units is now your new problem. You head in the same direction with the whole Microservices context.
A maintainable system is one built of components that are just simple and cohesive enough to be understandable by a human, but not any simpler. The right modularization is the hardest thing we do in software. The right size is hard to gauge, modules like that might be hard to name, and they are often hard to test. Sometimes one of those aspects must suffer for the others to do well.
There is no panacea to writing good code. Whatever principle you come up with, you can still write bad code that outwardly seems to be motivated by that principle.
I firmly believe that writing good code is a craft. I agree with you that 'the right size', and the right level of abstraction, is a hard thing.
But common patterns and principles can help us figure out how to do it better, as long as we don't think simply following them slavishly and cargo-cult-y is going to do it for us. After all, we're programmers, looking for common patterns and principles is what we DO.
O actually liked this article a lot, I think it provides more actual guidance and help in how to do things right than most articles in this genre, which are just rants without enough exmaples, or with examples that don't seem helpful to me. This one is helpful to me in improving my craft.
You can't be serious. I've worked many "Java Enterprise shop" and not only are they not burdered by >100k lines of spring xml lines but they are very sensible with what they test. the smartest ones mock nothing, the ones with younger developers tend to mock more.
Please HN, stop with the obviously inexperience and occasionally laughable (due to ridiculousness) "Java" claims.
Because I've worked in some that produced quality code, but I have certainly worked in some that did not. 100k may be an exaggeration, but not much more than by an order of magnitude.
Are you perhaps defining "enterprise" in such a way that necessarily excludes the possibility of poor code?
You omitted the qualification "that has code coverage as a religion" ... obviously those that "are sensible about what they test" do not have "code coverage as a religion".
25 comments
[ 2.9 ms ] story [ 61.7 ms ] thread- http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-...
- http://rubyrogues.com/056-rr-david-heinemeier-hansson/
- https://www.youtube.com/watch?v=9LfmrkyP81M
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.
[1] http://www.amazon.com/Growing-Object-Oriented-Software-Guide...
The main idea there is to unit test logic, but not unit test "coordination-code".
You can see this problem in any Java Enterprise shop that has code coverage as a religion: To make it possible to cover all that code (including all the boilerplate caused by the technologies selected), then we end up with a billion little classes that are managed by some kind of dependency injection system. Hundreds of thousands of lines of Spring XML configuration files, or their equivalent in annotations. Every piece is tested, but are all the pieces tested together, automatically? We quickly get into extremely large and expensive automation suites, or a whole lot of things that aren't really tested regularly, making all those unit tests a lot less valuable.
We can't wish complexity away: Make every unit too small, and the management of the units is now your new problem. You head in the same direction with the whole Microservices context.
A maintainable system is one built of components that are just simple and cohesive enough to be understandable by a human, but not any simpler. The right modularization is the hardest thing we do in software. The right size is hard to gauge, modules like that might be hard to name, and they are often hard to test. Sometimes one of those aspects must suffer for the others to do well.
I firmly believe that writing good code is a craft. I agree with you that 'the right size', and the right level of abstraction, is a hard thing.
But common patterns and principles can help us figure out how to do it better, as long as we don't think simply following them slavishly and cargo-cult-y is going to do it for us. After all, we're programmers, looking for common patterns and principles is what we DO.
O actually liked this article a lot, I think it provides more actual guidance and help in how to do things right than most articles in this genre, which are just rants without enough exmaples, or with examples that don't seem helpful to me. This one is helpful to me in improving my craft.
Please HN, stop with the obviously inexperience and occasionally laughable (due to ridiculousness) "Java" claims.
Could you expand on this point? I can't imagine testing without some sort of mocks.
Because I've worked in some that produced quality code, but I have certainly worked in some that did not. 100k may be an exaggeration, but not much more than by an order of magnitude.
Are you perhaps defining "enterprise" in such a way that necessarily excludes the possibility of poor code?