Classes for all the things?

Firstly, there is nothing about the problem that calls for object-orientation. As the author realizes, the classes in the class-based implementation are non-contributing baggage.

All the problem description actually calls for is three functions and a conditional clause. The implementation using functions presented here, however, is considerably more complicated than that, possibly because the author chose (deliberately or not) to attempt to mirror the form of the class-using solution.

This code was written for illustrative purposes, but the same sort of thing happens in real-world programming when people make a-priori decisions about the style of a solution, rather than be guided by the requirement. Having an preference for 'sophisticated' styles exacerbates the problem.

A common justification for this sort of complexity is that it makes the code more reusable, and in some cases it is justified. Whenever using that justification, however, one should consider how much simplification is actually achieved, and whether its reuse is likely, and weigh that against the immediate costs of the extra complexity.

Another justification is that it promotes correct use, and again this is sometimes justified. Note, however, that neither of solutions enforce one of the few usage rules of the example: that the normalization function should be applied before the calculation. Anyone creating his own concrete derivation from AbstractCalc has to remember to call the normalization function, and gets no warning if he fails to do so.