This isn't a strategy pattern but a lookup with functions. For a strategy pattern the outside world would provide the handler to the function that generates the bonus. Now instead you pass a type and get the rule in getBonus (either via a lookup or some if-statements). As a result of that it's getBonus responsibility to get the correct rule. With a strategy pattern you would delegate that responsibility to the outside world (also known as the 'inversion of control' principle).

You could of course call this 'too theoretical to be practical', but 'assign responsibilities to objects' is the foundation of OOP. And with the strategy pattern being an OOP design principle this sums op to you ignoring the main point of the pattern.

I think the main point you are missing here is that 'design patterns' are about 'design', not about implementation. How exactly a mapping between a type and a handler is done isn't the business of a design pattern. However, if and where the mapping is done is very much the domain of design patterns. Only in your examples that actually didn't change.

O, and in your last example: you can just give the validator class methods for each validation rule. That class would then delegate the validation to the correct rule. This is known as a facade, an object that acts as a single point of entry into a bigger module. At this moment you could literally append the value of the second argument to the method name and save yourself the lookup.