4 ms·
(OP here.) I agree that code examples would be better than intangible statements; I included a few samples in early drafts of this post, but ultimately conclude
by lbarrow 13y ago
(OP here.) I agree that code examples would be better than intangible statements; I included a few samples in early drafts of this post, but ultimately concluded they made it too long.
I'm not saying we shouldn't try to make components reusable or that we shouldn't use abstractions. Rather, we should introduce reusable components when they're actually reused rather than just used once. Component re-use should be introduced into a program lazily.
In the Minecraft example, once I add the Cat class, I would go back and refactor the Dog and Cat classes to inherit from Pet. The point I'm trying to make in the blog post is that I wouldn't do that until I had actually written at least two classes that I knew would be inheriting from the Pet class.
- hackinthebochs 13y agoYes, it was clear what your point was. My point is that there is code in your Dog class that would do well on its own, irrespective of any supposed Cats or Chickens. Separating positioning/movement code and barking code makes real design sense. Separation of Concerns is at times the antithesis of YAGNI.
- vidarh 13y agoYou are assuming that you know upfront which of that code actually will be separate. Some of it may seem very obviously separate, but that does not mean it is clear what the generic version will look like for all practical use cases. E.g. a generic "move" method may look substantially different if it is to only deal with pets that walk on the ground vs. handle pets that fly too. How much do you generalize it in advance before it is too much? If the code really is becoming so large it is a maintenance issue, then sure, yes, separate it anyway. But do it explicitly for that reason.