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

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.