Let me tell you a story. The story is about someone I knew back when I was doing my MSc. He was really bright, but he had to repeat a year in the papers part of his MSc. Why? Because he didn't get statistics. Differential equations? No problem. Topology? No problem. Operations research (which was his actual topic)? A walk in the park. Statistics? He just couldn't get it.
Why not? "I read the book, and I think I understand, and then I come to the examples, and I can't see why they use the method they use, why that is a good method for that problem." I hope it made a difference to him when I replied "You can't see why method X is a good choice for problem Y because it isn't. If your goal is to illustrate the workings of method X, problem Y will do. But if your goal is to actually solve problem Y, method X is the last thing you should try." I actually worked through a couple of famous textbooks, example by example, and found that for more than half of the problems, if you followed the advice in the book about how to select a method, you would never select the method in the example, and the method you would select instead gave better and on occasion much better results. In this particular case, I don't give a damn about what {1@0. 0@} looks like in a debugger, BECAUSE IT NEVER DID APPEAR IN A DEBUGGER. The one method needed to solve the problem is 18 lines. The test code, including all available test cases, is 27 lines, of which 18 lines is the test data. Tests were needed primarily to sort out what the problem actually *was*; exercism doesn't even try to provide good specifications. No debugging time at all was needed, precisely because the code was so simple and obvious. If it *had* been needed, viewing the result right next to the expression that yielded it would have given me all the context I needed, in one window. If you want to learn how to design a good set of classes, this is an absolutely dreadful problem. In fact ALL of the exercism problems are going to be dreadful for *that* purpose because they are provided for languages that do not *have* classes. If you want to learn how to *solve problems*, then you need to learn to write code that is simple, clear, testable, and so on. You certainly need to learn how to use what is already there in the language (except where that is expressly forbidden). I completely agree that designing a good set of classes is a very very important skill for anyone who wants to do OOP. I completely agree that practising this on problems you can hold in your head is a good idea. I completely agree that if *that* is your objective, writing minimalist code is not the best strategy. The problem with exercism is that while it does have a criterion by which you can tell whether you have *solved the problem*, it provides *no* way to assess your class design. You don't get told "this is good, that is bloated"; there is no feedback about the *quality* of your code except via comments from those few people who can be bothered to look at other people's solutions and comment on them. And since many of them will also be beginners, their comments may not always help. This particular problem is very similar to a "Langton's Ant" problem my old department gave to students, who were expected to solve it in two or three hours. And ALWAYS, the thing that held them back was creating classes they didn't need and agonising over what data and methods should go where (and then getting it wrong, such is the nature of Java). When a problem can be solved quite directly in 18 lines of clean code, you are going to have a very hard time persuading me that even one more class pays for itself, especially in a system with a rich class library of stuff you don't have to write. "You Aren't Gunna Need It" is a good slogan. "If you didn't write it you didn't wrong it" is another.