拟人化界面——好主意还是坏主意？
一段时间以来，我一直试图将我给接口的名称拟人化（意味着人类可读），对我来说，这与给接口一个基于角色的名称相同 - 试图在名称中捕获接口的用途。
我正在与其他开发人员进行讨论，他们认为这有点奇怪和幼稚。
SO的人们怎么看？
示例（C# 语法）：
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
{
}
I have for some time tried to anthropomorphise (meaning human readable) the names I give to interfaces, to me this is the same as give an interface a role based name – trying to capture the purpose of the interface in the name.
I was having a discussion with other developers who think this is a little strange and childish.
What do the folks of SO 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
{
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
IThinkItsATerribleIdeaIThinkItsATerribleIdea当然，您应该始终选择人类可读的标识符。就像：将它们传达的含义传达给那些不像您一样熟悉代码要解决的问题的人。
然而，使用长标识符并不会让你的标识符更“可读”。对于任何有相当经验的程序员来说，“tmp”传达的信息与“temporaryVariable”一样多。 “i”与“dummyCounter”等也是如此。
在您的特定示例中，接口名称实际上非常烦人，因为习惯于开发面向对象系统的人会将继承读取为“is a”。而“SomeClass 是一个 IHaveMessageParameters”听起来很愚蠢。
尝试改用 IMessagePrinter 和 IMessageParameterProvider。
Of course you should always choose identifiers which are human readable. As in: transport the meaning which they convey even to somebody who is not as familiar with the problem to be solved by the code as you are.
However, using long identifiers does not make your identifiers more 'readable'. To any reasonably experienced programmer, 'tmp' conveys as much information as 'temporaryVariable' does. Same goes for 'i' vs. 'dummyCounter' etc..
In your particular example, the interface names are actually quite annoying since somebody who's used to developing object oriented systems will read the inheritance as 'is a'. And 'SomeClass is a IHaveMessageParameters' sounds silly.
Try using IMessagePrinter and IMessageParameterProvider instead.
是的，这听起来是个好主意。
还有什么选择呢？
代码应该是人类可读的。任何傻瓜都可以编写计算机可以理解的代码。困难的部分是编写人类可以理解的代码。
人类必须维护代码，因此尽可能易于维护非常重要 - 这包括代码应该尽可能具有可读性。
Yes, that sounds like a good idea.
What's the alternative?
Code should be human-readable. Any fool can write code a computer can understand. The difficult part is writing code a human can understand.
Humans have to maintain the code, so it's pretty darn important that it is as easy to maintain as possible - that includes that the code should be as readable as possible.
接口描述了行为，因此我命名它们是为了传达它们所要求的行为。这个“一般”意味着该名称是动词（或副词）或某种形式的动作描述短语。与界面中的“I”相结合，这看起来就像您正在做的事情...
ICanMove、IControllable、ICanPrint、ISendMesssages 等...
使用 IControllable、IDisposable、IEnumerable 等中的副词传达与动词相同的想法形式并且更简洁，所以我也使用这种形式...
最后，比您命名界面更重要（或至少同样重要）的是，使您设计的界面尽可能小并在逻辑上包含在内。您应该努力让每个接口代表尽可能小的且逻辑上连接的一组方法/属性。当一个接口包含太多内容，以至于没有明显的名称来描述它所要求的所有行为时，这表明它包含的内容太多，并且需要将其重构为两个或更多较小的接口。因此，按照您建议的方式管理界面有助于强制实施这种类型的组织设计，这是一件好事。
Interfaces describe behavior, and so I name them so as to to communicate the behavior they are mandating. This 'generally' means that the name is a verb, (or adverb) or some form of action-describing phrase. Combined with the "I" for interface, this looks like what you are doing...
ICanMove, IControllable, ICanPrint, ISendMesssages, etc...
using adverbs as in IControllable, IDisposable, IEnumerable, etc. communicates the same thought as a verb form and is terser, so I use this form as well...
Finally, more important (or at least equally important) than what you name the interface, is to keep the interfaces you design as small and logically contained as possible. You should strive to have each interface represent as small and logically connected a set of methods/properties as possible. When an interface has so much in it that there is no obvious name that would describe all the behavior it mandates, it's a sign that there is too much in it, and that it needs to be refactored into two or more smaller interfaces. So, maming interfaces in the way you are proposing helps to enforce this type of organizational design, which is a good thing.
使用简单的人类可读名称并没有什么奇怪的。但是使用
I作为界面也代表第一人称I，就好像它在谈论自己一样......有点不寻常，是的。但底线是，任何对你有用并且被你和你的团队理解的东西都可以。你必须选择有效的方法。
There's nothing strange about using simple human-readable names. But using the
Ifor interface to also stand for the first-personIas though it's talking about itself... is a little unusual, yes.But the bottom line is, whatever works for you and is understood by you and your team is fine. You gotta go with what works.
在我看来，这种方法只会给开发人员增加更大的负担，因为它将 I 作为句子的一部分。例如，我不认为
IDisposable比ICanBeDispose更难阅读。In my opinion this approach just adds a greater burden on the developers to come up with such names since it intergrates the I as part of a sentence. I don't find
IDisposablefor example to be more difficult to read thanICanBeDisposed.在OP的示例中，拟人化的方式与替代方案进行了很好的比较 - 例如：IShowMessages与IMessageShower之类的东西。但是——情况并非总是如此。我在编写游戏对象时使用过的接口包括：IOpenClosable 和 ILockable。像 ICanBeOpenedAndClosed 和 ICanBeLocked 这样的替代方案会更加冗长。或者您可以简单地执行 IAmOpenClosable 和 IAmLockable - 但随后您将添加“Am”只是为了拟人化效果，而没有真正的信息优势。如果传达的信息量相同，我完全赞成尽量减少冗长。
In the OP's examples, the anthropomorphic way compares well against alternatives - eg: IShowMessages vs. something like IMessageShower. But - this is not always the case. Interfaces I have used when programming game objects include: IOpenClosable and ILockable. Alternatives like ICanBeOpenedAndClosed and ICanBeLocked would be more verbose. Or you could simply do IAmOpenClosable and IAmLockable - but then you'd be adding the "Am" just for the anthropomorphic effect with no real information benefit. I am all for minimizing verbosity if the same amount of information is conveyed.
只要所要实现的目标的语义不会丢失，并且简洁性不会受到不可挽回的损害（IDoLotsOfThingsWhichInincludesTheFollowingColonSpace ...）。我通常不介意除了我自己之外的其他人这样做。尽管如此，在很多情况下，简洁是最重要的，但在这种情况下这是不可接受的。
So long as the semantics of what is trying to be achieved aren't lost and terseness isn't irreparably compromised (IDoLotsOfThingsWhichIncludesTheFollowingColonSpace...). I wouldn't generally mind somebody other than myself doing it. Still, there are plenty of contexts in which terseness is paramount, in which this would be unacceptable.
老实说，在第一人称中故意使用“I for Interface”约定似乎有点愚蠢。一开始是一个可爱的双关语，但后来却变得不可能始终如一地遵循，最终会导致意义变得模糊。也就是说，您的独立示例读起来足够清楚，我不会有任何问题。
Intentionally using the 'I for Interface' convention in the first person seems a bit silly to be honest. What starts out as a cute pun becomes impossible to follow consistently, and ends up clouding meaning later on. That said, your standalone example reads clearly enough and I wouldn't have a problem with it.