What is a good (natural-language) naming scheme for belonging or property interfaces

Question

NOTE: This is not the popular interface naming question about using or not using "I" at the beginning.

I encounter often the problem to name an interface, which indicates a belonging or property of a class.
(Please see following list)

Let's brainstorm, what kinds of interfaces are there?

• Indicate the "kind" of a class
  DataStructure, Number, Thing

• Indicate the "profession" of a class
  Comparator, Executor, Listener

• Indicate a possible action performed with a class
  Comparable, Executable, Closeable

The above are all clear to anyone, but let's get to my problem:

• Indicate a belonging or property of a class
  HasListener, LinksToRoot, BelongsToParent, KnowsSibling, ContainsChildren, Named, WithDescription, ...?

So, the last point is my problem. My english is not perfect, but even I feel strange about such names. They sound to me less successfully chosen then other, less meaningful. But I often end up choosing right this kind of names.

It is even a greater discomfort in C# where interfaces are expected to start with an 'I':
IHasListener, IKnowsSibling, ...
Sound to me like LOLSPEAK "I can haz a kitteh, tawtally being full of cuteness, OMG!@#!"

So, how should I name an interface which indicates a belonging or property of a class?

Answer 1

The problem is the way you choose to describe the "belonging of a property".

Most of your examples you gave can be mapped to the other categories you mentioned.

Just a few, for example:

HasListener => implements Listenable

ContainsChildren => implements Parent

WithDescription => implements Descriptable

Try to stick with more conventional naming schemes, preferably ones that describe your object in the best, more readable manner.

Also, make sure you are not over-interfacing your classes with useless interfaces. Make it very concise and to-the-point, otherwise you'll developers reading your code will get lost very fast.

Answer 2

In some of the problem cases that you outline, I think there may be an answer by looking "from the other side":

HasListener -> Speaker
LinksToRoot, HasParent -> Child (or perhaps Node)
ContainsChildren -> Parent

Of course, different cases will be more or less obvious.