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
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
but (Yes, these aren’t functionally equal. That’s part of why I said it wasn’t that good of an example)