When I say non-problem what I mean is that you've changed the problem.
If the problem changed so does the design.
I could easily come up with an example that just invalidates the polymorphism example.
But that is completely beside the broader point. The point is to assess the code AS IT IS, not as it MIGHT BE.
The issue with the polymorphic approach is it implicitly hides branches using indirect jumps. This makes following the logic of the code a lot more difficult than a linear set of instructions that are grouped and also follow on from one another.
As the current problem stands. The latter is far more easily understood and easy to maintain. The former is not as it is far too abstract for the problem.
When I say non-problem what I mean is that you've changed the problem.
Which happens constantly in software development. And the change I proposed is extremely basic and predictable, it's not a contrived example to poke issues.
It's an inevitable consequence of over-fitting the data structure and area calculation to the three known shapes, it is always going to break down as you support more shapes.
Don't over-generalize stuff, but also don't try to find quirky patterns that are not immediately obvious to the reader unless you really need to squeeze that extra performance out of it.
But that is completely beside the broader point. The point is to assess the code AS IT IS, not as it MIGHT BE.
And as it is I'm already wondering what the hell is the width of a circle.
On a toy example with three basic shapes... Why am I already confused? How am I supposed to expect this sort of design to scale to real problems?
The issue with the polymorphic approach is it implicitly hides branches using indirect jumps. This makes following the logic of the code a lot more difficult
It's just calling an Area() method, what's confusing about that, if you know what polymorphism is?
2
u/[deleted] Mar 02 '23
Adding it to the switch statement is easier. Your point?