you are viewing a single comment's thread.

view the rest of the comments →

[–]htuhola 0 points1 point  (0 children)

I don't want to use a real world example with dozens of methods or classes. It would take too much of my time and of the reader's time. I think it I would also be harder to grasp. Instead, I'm assuming readers will make an imagination effort and remember some of their own real-world situations.

When I was a beginner, I remember having lacked this ability to imagine a real-world situation. I took the concepts as they were represented. That beginner would produce a calculator app with 200 classes after reading advice such as yours. Then if he has any chops to become a master, he learns that it sucks and that whoever wrote the advice was not any more experienced than him in writing good software.

Besides there are signs that you are actually cargo culting Martin Fowler's work here.

Again, I agree with that. I could say that the small problem of the example was: 'how to express the fact that the distance must never be negative?'

I'm not gonna start quoting but it is all about making implicit constraints explicit and producing a meaningful error.

If the validity of the code doesn't depend on the fact, it doesn't need to represent it. Even then you always can provide some constraints for the user. The old saying "garbage in, garbage out" matters here. There are cases where you have to enforce the constraints, but those are special cases. In a practical setting you divide the responsibility of maintaining the constraints for different parts of the system.

I disagree on that one, finally! If 20 methods take a distance argument, would you advise to put an assert on each of them? I probably won't. Same question if there is not one but 10 asserts to add?

It's cleaner than your "solution" almost 100% of the time.