I think naming should reflect whether a class encodes business logic or is ‘glue’ to make that work.

Nowadays, many people use languages with huge libraries. Consequently, most logic is business logic. There, name classes (and functions, and argument names) after their business use, not after their implementation.

However, parts that aren’t business logic such as wrappers of external libraries or generic containers you have to implement because they aren’t available in the language’s ecosystem should use generic names, and can use pattern names, because those tell callers what they do.

As a made up (and not that good) example, one would have

   def pow(a,b)

but

   def valueAfterNYears(initialValue, interestPerYear)

(Yes, these aren’t functionally equal. That’s part of why I said it wasn’t that good of an example)