一段时间以来，我试图将我给接口的名称拟人化（意思是人类可读），对我来说，这与给接口一个基于角色的名称相同——试图在名称中捕捉接口的目的。
我正在与其他开发人员进行讨论，他们认为这有点奇怪和幼稚。
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
{
}
当然，您应该始终选择人类可读的标识符。如：将它们传达的含义传递给不熟悉代码要解决的问题的人。
但是，使用长标识符不会使您的标识符更“可读”。对于任何经验丰富的程序员来说，'tmp' 传达的信息与 'temporaryVariable' 一样多。'i' vs. 'dummyCounter' 等也是如此。
在您的特定示例中，接口名称实际上很烦人，因为习惯于开发面向对象系统的人会将继承读取为“is a”。'SomeClass is a IHaveMessageParameters' 听起来很傻。
尝试改用 IMessagePrinter 和 IMessageParameterProvider。
是的，这听起来是个好主意。
有什么选择？
代码应该是人类可读的。任何傻瓜都可以编写计算机可以理解的代码。困难的部分是编写人类可以理解的代码。
人类必须维护代码，因此尽可能易于维护是非常重要的——这包括代码应该尽可能可读。
使用简单易读的名称并不奇怪。但是使用Ifor 界面也代表第一人称I，就好像它在谈论自己......有点不寻常，是的。
但最重要的是，任何对你有用并且被你和你的团队理解的东西都很好。你必须选择有效的方法。
在我看来，这种方法只是给开发人员增加了更大的负担来想出这样的名字，因为它将 I 作为句子的一部分。例如，我没有发现IDisposable比ICanBeDisposed.
接口描述行为，所以我命名它们是为了传达它们所要求的行为。这个“一般”意味着这个名字是一个动词，（或副词）或某种形式的动作描述短语。结合界面的“I”，这看起来就像你在做什么......
ICanMove、IControllable、ICanPrint、ISendMesssages 等...
在 IControllable、IDisposable、IEnumerable 等中使用副词与动词形式传达相同的思想并且更简洁，所以我也使用这种形式......
最后，比您命名接口更重要（或至少同样重要）的是使您设计的接口尽可能小并在逻辑上包含。您应该努力让每个接口尽可能小并在逻辑上连接一组方法/属性。当一个接口有太多内容以至于没有一个明显的名字可以描述它所要求的所有行为时，这表明它里面有太多的东西，并且需要将它重构为两个或更多更小的接口。因此，以您提议的方式创建接口有助于实施这种类型的组织设计，这是一件好事。
在 OP 的示例中，拟人化方式与替代方式相比效果很好 - 例如：IShowMessages 与 IMessageShower 之类的东西。但是 - 情况并非总是如此。我在编写游戏对象时使用的接口包括：IOpenClosable 和 ILockable。ICanBeOpenedAndClosed 和 ICanBeLocked 等替代方案会更加冗长。或者您可以简单地执行 IAmOpenClosable 和 IAmLockable - 但随后您将添加“Am”只是为了拟人化效果而没有真正的信息优势。如果传达相同数量的信息，我完全赞成尽量减少冗长。
只要试图实现的语义没有丢失并且简洁性没有受到不可挽回的损害（IDoLotsOfThingsWhichIncludesTheFollowingColonSpace ...）。除了我自己之外，我通常不会介意其他人这样做。尽管如此，在很多情况下，简洁是最重要的，在这种情况下这是不可接受的。
老实说，故意在第一人称中使用“I for Interface”约定似乎有点愚蠢。一开始是一个可爱的双关语变得不可能始终如一地遵循，并最终使含义变得模糊。也就是说，您的独立示例读起来很清楚，我不会有问题。