But it also means that you are introducing a lot of extra classes that do almost nothing but wrap primitives and provide little or no additional behaviour.
If you do need to pass in additional information, refactor and change the primitive to an object when you really need to, not because you might need it at some point in the future (and the chances are you won't).
> If you do need to pass in additional information, refactor and change the primitive to an object when you really need to, not because you might need it at some point in the future (and the chances are you won't).
That's a lot harder than doing it right to begin with, and requires significant API-breaking changes across the code base.
Due to the cost of doing so, it's far more likely that the code will be hacked poorly to incorporate the necessary addition, as the substantial changes now required would be much too costly.
YAGNI is misused to justify being lazy. You're always going to need maintenance (except when you have the rare piece of throw-away code), certain approaches are always going to incur high costs to maintenance and future development. YAGNI doesn't apply when past experience provides sufficient evidence that you do need it, and you need it now, when you're writing the code.
And you are correct that there are cases where this is true - but the best approach is to use an element of judgement and make a call when this is likely to pay off in the long term. Always using primitives for everything or never using primitives because you might need to augment them structurally at some point are both silly extremes that are equally bad.
True, they are silly extremes. But as guidelines they are not equal. One may lead to a few extra "waste" classes, but the other can fook things up.
They are to be taken in the same vein as "prefer implementation to extension (program to interfaces rather than classes)" and so on. Not gospel, but advice from some of those who have been down both roads and are calling back to us. Advice meant to give you pause as you set about building that subclass.
It should be obvious that design strategies that allow change without breaking signatures are good things. Maybe they are not needed or wanted absolutely everywhere, but certainly, if there is any doubt, they should be used.
Well, my experience redesigning large-scale enterprise applications built to be "generic" is that almost nobody gets the balance right but by far the worst applications to work with are the over-architected over-generic solutions.
> Always using primitives for everything or never using primitives because you might need to augment them structurally at some point are both silly extremes that are equally bad.
If you do need to pass in additional information, refactor and change the primitive to an object when you really need to, not because you might need it at some point in the future (and the chances are you won't).