On Wed, 1 Mar 2023 at 11:34, Yehezkel Bernat via SG20
<sg20_at_[hidden]> wrote:
>
> Couldn't agree more. This transformation is easy to do when you have a single member function, not when you have dozens of them, and more class trees for other parts of your system. Not to mention that they picked up only the simple shapes, where it's possible to multiply width by height and then by some factor :)
>
> BTW, for the "corner count" example, I think common guidelines would suggest making it a data member that is saved in the base class and initialized by the c-tor, not a virtual function (but some maybe wouldn't, as it increases the size of each object).

I don't have a problem with that writeup. It's applying architectural
knowledge of the problem domain to extract common properties
into common code, removing the unnecessary flexibility-boundary
(virtual functions) that it was beyond before, and then, with
the table approach, it brings back the polymorphic nature of the code,
allowing a single piece of code to have multiple behaviors.
And when doing so, it achieves 10-15x performance, which isn't
necessarily a micro-optimization, it's just avoidance of overhead
that may well be unnecessary for a particular problem domain.

The only thing that throws me off in that writeup is that I don't know
what rule and recommended by whom and where they're referring to with
'Prefer polymorphism to “if/else” and “switch”'. I find such a
gross-overgeneralization rule something to avoid like a plague. If
such
a rule exists in some recommendation, I find that a much bigger
problem than what the article walks us through. The actual content
and the end result, and the path to it in the article is something
that prompts applause rather than disdain or skeptical rejection from
me.