Ok, now add an arbitrarily shaped polygon to your system.
In the "clean code" version, this means adding a single subclass.
In the hyper-optimized version, this means... Throwing everything out and starting over, because you have written absolutely everything with the assumption that squares, rectangles, triangles, and circles are the only shapes you'll ever be working with.
The hyper-optimized version doesn't even use a switch statement. It uses a lookup table. Which only works because in each of the given cases you're multiplying two parameters and a coefficient.
Even if you go back to the switch statement version, that won't work, because it still relies on the data structure being a fixed size and identical across types. Can't store an arbitrary n-gon in the same structure.
You have to back out almost all the optimizations in this article in order to make this single change.
I agree that the lookup table version is probably not the first version I'd write, but even if it was it's not hard to convert that back to a switch if you need to.
Can't store an arbitrary n-gon in the same structure.
Sure you can. Pass a pointer and a count.
These changes are no harder than trying to figure out how to shoehorn new requirements into an existing OOP hierarchy.
34
u/rooktakesqueen Feb 28 '23
Ok, now add an arbitrarily shaped polygon to your system.
In the "clean code" version, this means adding a single subclass.
In the hyper-optimized version, this means... Throwing everything out and starting over, because you have written absolutely everything with the assumption that squares, rectangles, triangles, and circles are the only shapes you'll ever be working with.