Names for generic classes - how to avoid naming them just "object"? Use synonyms?

Question

When programming, I often end up naming some generic class (think of an abstract base class for stuff you manage in your project) something like FooObject, FooComponent or FooItem (where Foo is an abreviation of project name). The problem is, that these names are used so often, they become meaningless - I mean, when I'm talking about an "object", no-one knows whether I mean "a subclass of FooObject", or an ordinary object.

I think that a good list of synonyms for "object", "component", "callback", "handler", "action" and so on would help, because we could just redefine these world on a per-project basis. You could even make up some totally nonsense word and define your meaning in documentation. I think it would be clearer than naming stuff "objects".

Here's what I mean by "nonsense" (taken from Alice in Wonderland):

Twas brillig, and the slithy toves

Did gyre and gimble in the wabe:

All mimsy were the borogoves,

And the mome raths outgrabe.

Maybe you can have some nice words you use in such cases?

How do you deal with similar situations in your projects?

[ Related: How to avoid general names for abstract classes? ]

• Doc Brown: Well, sure the top answer of the "related" question you linked to does not apply to your case as well? From what you wrote so far I tend to vote for closing your question as beeing a duplicate of that other question.
• mik01aj: Well, this answer says to turn the base class to some separate classes, and while this is be a good idea in some cases, sometimes you have a hierarchy with clear is-a relations and you'd like to have the base class.
• AakashM: 'when I'm talking about an "object", no-one knows whether I mean "a subclass of FooObject", or an ordinary object.' - you can resolve this by saying 'object' when you mean an ordinary object, and 'subclass of FooObject' when you mean a subclass of FooObject.
• MetaFight: Surely you'd want to to call a subclass of a FooObject a foo no? I suffix all my abstract base classes with base so in my case the base class would be a FooBase so I can reasonably refer to all subclasses as Foos.

Answer 1

On the matter, Kent Beck said:

"[...] The names should be short and punchy. However, to make the names precise sometimes seems to require several words. A way out of this dilemma is picking a strong metaphor for the computation. With a metaphor in mind, even single words bring with them a rich web of associations, connections, and implications. For example, in the HotDraw drawing framework, my first name for an object in a drawing was DrawingObject. Ward Cunningham came along with the typography metaphor: a drawing is like a printed, laid-out page. Graphical items on a page are figures, so the class became Figure. In the context of the metaphor, Figure is simultaneously shorter, richer, and more precise than DrawingObject."

(From Marcio Aguiar's answer in https://stackoverflow.com/questions/38019/whats-the-best-approach-to-naming-classes)