3 ms·

I think the point is avoiding complexity until absolutely necessary. Splitting code and creating abstractions "because it will make doing X easier in the future

• zmmmmm 17y ago
  That's the point that seems to be most missed here. It makes total sense to split things into 7 different classes when you actually need different implementations of all those parts so that the abstractions you've made are useful. The problem with demonstrating these things in books (or in general) is that your examples have to be simple to be comprehensible. But the presumption is that the techniques are being applied into reality to a much more complex system. I'm sure if the book had injected 20,000 lines of code into the example he would have written a blog post about how the book should have used a simpler example to demonstrate the point while having no complaint about the fact that it used 7 classes to do it. I think because of this tendency in books and courses to demonstrate complex OO techniques with simple examples many people come away with the attitude that you should do all this stuff pre-emptively rather than "on demand". I'm not sure that was ever really the intention, but it has resulted in a lot more overly abstracted code being produced in the world than necessary.