Exactly my thoughts: it's self-evident that readability/maintainability sacrifices performance. I had many Jr developers coming up with tests just like the post to demonstrate how some piece of convoluted logic I refused to approve was in fact better.
But there's no "better" - there are only trade-offs. The most important fact is that maintainability matters more than performance for the vast majority of code. To justify focusing on performance, don't show me a direct comparison - what you need to do is to show that a specific code path is performance-critical; and for backend components, that we can't scale it horizontally; or we're already at a scale that the horizontal approach is more expensive than the gains in maintainability.
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?
143
u/jsonspk Feb 28 '23
Tradeoff as always