I saw in an application where it had interfaces such as:
IHasContent
IHasValue
IHasMesh
IHasGeometry
IHasTransformation
Should they not be?:
IHaveContent
IHaveValue
...
Or?:
IIncludeContent
IIncludeValue
...
Personally I am leaning towards just making them:
IContent
IValue
IMesh
IGeometry
ITransform
Because isn't ISomething
already implies that it has that something
?
As for the last one, should I make it ITransformable
instead?
I think using I + (Has/Have/Include/Exist, etc) + Name
makes the interface names more confusing.
Any ideas on how to come up with better interface names that doesn't feel awkward, is to the point, and gets the meaning across?
Some of these names (Content, Value, etc) are vague, and do little to describe the content/behaviour of an item. In general, names should be as specific and distinct as possible - IScriptParameter might be more descriptive than IValue. As your project grows, having more descriptive names will make your types much easier to distinguish (if you're not careful you could end up with IValue and INumber and IAmount to handle variations of "values"!)
If your interface (e.g. IMesh) means "provides the properties of a mesh", then IMesh is a perfectly fine name - it describes the fact that you can treat the object as if it were a Mesh.
If your interface is used to apply an action (eg. to render the object as a mesh, or to apply a transform to the object), then consider using a verb/adjective rather than noun naming (e.g. IRenderable, ITransformable) - this is a common pattern in .net (IEnumerable (verb/adjective) rather than ICollection (noun), for example)
To me, "IHasMesh" sounds more like IMeshContainer - i.e. it is an object that contains a mesh, and the interface allows me to "get the mesh". So it would not allow me to act on or query data within the mesh, but simply fetch an entire Mesh object through the interface.
So I would use: