Is there a dictionary about a common programming dictionary?

Question

When I need a name for a new class that extends the behavior of an existing class, it is usually difficult for me to find a name for it.

For example, if I have a class MyClass, then the new class can be called something like MyClassAdapter, MyClassCalculator, MyClassDispatcher, MyClassParser, ...

This new name should, of course, represent the behavior of the class and ideally be the same as the design pattern in which it is used (Adapter, Decorator, Factory, ...). But since we do not abuse design patterns, this is not always the solution :)

So, do you know a dictionary or a list of common words that we can use to represent class behavior that contains a brief description of expected behavior? Some examples: replicator, shadow, token, acceptor, worker, cartographer, driver, bucket, socket, validator, wrapper, parser, verifier, ...

You can also see this list as a trickster for metaphors, with which you can better understand your problem domain.

Answer 1

I would recommend not using design patterns in names. You started with the name MyClass and expanded it to MyClassAdapter, MyClassCalculator, MyClassDispatcher, MyClassParser, etc.

But since you know that these are classes, and they are yours, why not adapters, a calculator, a dispatcher, a parser.

But does the adapter really do what it says? Does the calculator calculate absolutely anything, or is there a specific job?

Good names could be WindowToCommProtocol (name what it adapts), Payroll (calculation is just one task), UICentral (sounds like a dispatcher to me), etc. Calculators and parsers usually do not have to keep state as soon as their work is done, so they remind me more of functions rather than classes.

Answer 2

I think it's rather strange to try to reflect (or designate or suggest or mean or imply) the behavior of a class on its behalf. Of course, the behavior of a class is determined by its methods?

I also think that using my vocabulary will require you to subscribe to my way of thinking about the world. Even if we work in the same problem area (and I'm sure not), I don’t think it will be easy for you.

Therefore, I suggest you do what you almost offer yourself: to deduce your dictionary from the terminology of the problem area. This exercise will help you understand your domain.

Finally, instead of a dictionary, you might be better off reaching a thesaurus.