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? ]
FooObject
afoo
no? I suffix all my abstract base classes withbase
so in my case the base class would be aFooBase
so I can reasonably refer to all subclasses asFoo
s.