catwidget

Then somewhat later, Jolene Developer joins the project and is asked to fix an intermittent bug in CatWidget.

However, now every time a change is made to CatWidget, if the design is good then it should be fairly obvious whether it's a change to Widgetness, or a change to Catness.

If I chose instead to implement Widget, and derive DogWidget and CatWidget, then yes, I am imposing some additional burden on future developers to learn how the code is structured.

> Then somewhat later, Jolene Developer joins the project and is asked to fix an intermittent bug in CatWidget.

If one day we get sick of this code structure and wish we had taken the other route, we can quickly copy-paste and completely fork CatWidget with basically no risk of regression, and minimal effort.

The bug turns out to be partly due to the original Widget implementation, and partly due to Joe's changes - now Jolene not only has to fix CatWidget, but also examine DogWidget carefully to determine if a) the bug affects DogWidget too, and how, and b) whether or not to fix it, and how (which may be different from the CatWidget fix).

Rolling CatWidget's and DogWidget's Widgetness back together into a base class is now a very difficult refactoring job that is determined to take twice as long as just copy-pasting DogWidget and making Bird changes; doing the right thing by the code doesn't make economic sense.