views:

183

answers:

2

When I need a name for a new class that extends behaviour of an existing class, I usually have hard time to come up with a name for it.

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

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

So, do you know for a dictionary or a list of common words, that we can use to represent the behaviour of the class, containing a short description of the expected behaviour? Some examples: replicator, shadow, token, acceptor, worker, mapper, driver, bucket, socket, validator, wrapper, parser, verifier,...

You could also look at this list as a cheat sheet for metaphors, with which you can better understand your problem domain.

A: 

I think it's rather odd to try to reflect (or denote or suggest or mean or imply) the behaviour of a class from its name. Surely the behaviour of a class is defined by its methods ?

I think also that your using my dictionary would require you to subscribe to my way of thinking about the world. Even if we are working in the same problem domain (and I bet we're not) I don't think this would be easy for you to do.

I suggest, therefore, that you do what you almost suggest yourself: derive your own dictionary from the terminology of the problem domain. That exercise would assist you in understanding the domain.

Finally, rather than a dictionary, you might be better reaching for a thesaurus.

High Performance Mark
Well, there *are* common idioms for class (and method) names, and this is usually a *good* thing (think design patterns) to ease the learning curve of a new API.
Konrad Rudolph
+1  A: 

I'd recommend against using design patterns in names. You started with the name MyClass and extended it to MyClassAdapter, MyClassCalculator, MyClassDispatcher, MyClassParser, etc.

But since you know these are classes, and they are yours, why not Adapter, Calculator, Dispatcher, Parser.

But does Adapter universally do what it says? Does Calculator calculate absolutely anything, or is there a specific job?

Good names might be WindowToCommProtocol (name what it adapts), Payroll (calculation is but one task), UICentral (sounds like a dispatcher to me), etc. Calculators and parsers typically shouldn't retain state once their job is done, so those sound more like functions, not classes, to me.

Potatoswatter