Anthropomorphizing interfaces - a good idea or a bad idea?
I've been trying for a while to anthropomorphize (which means human readable) the names I give to interfaces, to me it's the same as giving an interface a role-based name - trying to capture the purpose of the interface in the name.
I have had a discussion with other developers who think this is a little weird and childish.
What do SO people think?
Examples (C # syntax):
public interface IShowMessages
{
void Show(string message);
void Show(string title, string message);
}
public class TraceMessenger : IShowMessages
{
}
public interface IHaveMessageParameters
{
IList<string> Parameters { get; }
}
public class SomeClass : IHaveMessageParameters
{
}
source to share
Interfaces describe behavior, so I name them to communicate the behavior they perform. This "usually" means that the name is a verb (or adverb) or some form of description of an action. Combined with the "I" interface for the interface, this is similar to what you are doing ...
ICanMove, IControllable, ICanPrint, ISendMesssages, etc.
using adverbs like in IControllable, IDisposable, IEnumerable, etc. conveys the same thought as the verb form and is a term, so I also use that form ...
Finally, more important (or at least not less important) than what you call an interface is to keep the interfaces you design as small and logically contained as possible. You should strive to ensure that each interface represents as small and coherent set of methods / properties as possible. When an interface has so much in it that there is no obvious name to describe all the behavior it defines, it is a sign that it has too much and needs to be refactored into two or more smaller interfaces. So game interfaces as you suggest helps provide this type of organizational design, which is good.
source to share
Of course, you should always choose IDs that are human readable. As in: carry over the value they convey even to someone who is not as familiar with the problem to be solved with code as you are.
However, using long identifiers does not make your identifiers more "readable". For any reasonably experienced programmer, "tmp" conveys as much information as a "temporary variable". The same goes for "i" and "dummyCounter" etc.
In your specific example, the interface names are actually very annoying, as someone who has used to develop object oriented systems will read inheritance as "is a". And "SomeClass is IHaveMessageParameters" sounds silly.
Try using IMessagePrinter and IMessageParameterProvider instead.
source to share
Yes, that sounds good.
What is the alternative?
The code must be human readable. Any fool can write code that a computer can understand. The hard part is the code that a human can understand.
People have to maintain the code, so it is very important that it is as easy to maintain as possible - this includes making the code as readable as possible.
source to share
There is nothing strange about using simple, human-readable names. But using an interface I
for an interface also means for the first person I
, as if he is talking about himself ... a little unusual, yes.
But the bottom line is what works for you and is understood by you and your team in order. You have to go with what works.
source to share
In the OP's examples, the anthropomorphic way matches up well with alternatives - for example: IShowMessages versus something like IMessageShower. But it is not always the case. The interfaces I have used when programming game objects are IOpenClosable and ILockable. Alternatives like ICanBeOpenedAndClosed and ICanBeLocked will be more verbose. Or you can just make IAmOpenClosable and IAmLockable, but then you would add "Am" only for anthropomorphic effect, with no real informational benefit. I keep everything to a minimum verbosity if the same amount of information is transmitted.
source to share
As long as the semantics of what is trying to be achieved is not lost and patience is not irreparably compromised (IDoLotsOfThingsWhichIncludesTheFollowingColonSpace ...). I wouldn't think about it at all, except me. However, there are many contexts in which patience is paramount, in which it would be unacceptable.
source to share
Deliberately using the first-person self-for-interface convention seems a little silly to be honest. What starts out as a cute pun becomes impossible to follow consistently, and eventually ends in meaning. However, your individual example reads clear enough that I would have no problem with it.
source to share