The table version also has something really interesting going for it: it just begs to be thrown out and replaced should new requirements come in that don't fit

The table version also has something really interesting going for it: it just begs to be thrown out and replaced should new requirements come in that don't fit with that design. If a new type of shape comes in that doesn't fit with the factor * width * height model (e.g., a trapezoid), we'd need to go back to the drawing board and figure out how to make the existing and new cases work harmoniously together. On the other hand, an abstract base class broadcasts the message that we should fold our new cases into the existing design -- that's what base classes are made for. But even when new cases don't fit neatly in the existing design, we often feel as programmers that we need to pay respect and deference to existing design, especially if it was made with extensibility in mind. And so we add more complexity (maybe we need an extra field or an extra method), make more kludges, and soon enough the original OO design is a mountain of complexity and has so much "gravity" that it's nearly impossible to escape it anymore -- nobody can imagine throwing it out and starting fresh, so it just keeps gaining complexity. And for all its complexity, it's also slower.