4 ms·

I can't really agree, although its hard to argue against a contrived example and a general rule that is almost a tautology (don't write code you don't need). A

I can't really agree, although its hard to argue against a contrived example and a general rule that is almost a tautology (don't write code you don't need). A lot of times "architecture astronauting" is simply good separation of concerns. To take the Dog example: there is a lot of code necessary to get a Dog into the world of minecraft that isn't specific to the concept of Dog at all, such as drawing itself, keeping track of its state in the world, etc. These are the types of concerns you would want in a base class of Dog and potential Cats and Chickens. This is something that should be factored out, not because you may eventually make a Cat, but because those concerns have no connection to the concept of Dog at all. Keeping such code together will just make comprehending the actual Dog specific code harder.

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 ago
  Yes, 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 ago
    You 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.

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 ago
Yes, 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 ago
  You 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.