拟人化界面 - 好主意还是坏主意？答案

【问题标题】：Anthropomorphising interfaces - good or bad idea?拟人化界面 - 好主意还是坏主意？
【发布时间】：2010-11-23 09:24:28
【问题描述】：

一段时间以来，我一直试图将我给接口的名称拟人化（意思是人类可读），对我来说，这与给接口一个基于角色的名称相同——试图在名称中捕捉接口的用途。

我正在与其他认为这有点奇怪和幼稚的开发人员进行讨论。

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
{
}

【问题讨论】：

public interface IHazTehCodez{IList<Codez> Codez{get;}}
所以 IDisposable 应该是 IAmDisposable 吗？但它如何应用于不习惯在接口前加上“I”的 Java 中？
我并不是说 IDisposable 是错的，我只是建议在命名我正在定义的接口时应该考虑接口的角色\可读性。

标签： c# interface role-based

【解决方案1】：

说实话，故意在第一人称中使用“I for Interface”约定似乎有点愚蠢。一开始是一个可爱的双关语变得不可能始终如一地遵循，并最终使含义变得模糊不清。也就是说，您的独立示例读起来很清楚，我不会有任何问题。

【讨论】：

【解决方案2】：

接口描述行为，因此我命名它们是为了传达它们强制执行的行为。这个“一般”意味着这个名字是一个动词，（或副词）或某种形式的动作描述短语。结合界面的“我”，这看起来就像你在做什么......

ICanMove、IControllable、ICanPrint、ISendMesssages 等...

在 IControllable、IDisposable、IEnumerable 等中使用副词与动词形式传达相同的思想并且更简洁，所以我也使用这种形式......

最后，比您命名接口更重要（或至少同样重要）的是，使您设计的接口尽可能小且在逻辑上包含。您应该努力让每个接口尽可能小并在逻辑上连接一组方法/属性。当一个接口有太多内容以至于没有一个明显的名字可以描述它所要求的所有行为时，这表明它里面有太多的东西，并且需要将它重构为两个或更多更小的接口。因此，以您提议的方式创建接口有助于实施这种类型的组织设计，这是一件好事。

【讨论】：

+1 这也称为Interface Segregation Principle 或简称为role interface。如果我们可以在这些"roles" 中包含一些代码，那将会很有趣。

【解决方案3】：

在 OP 的示例中，拟人化方式与替代方式相比效果很好 - 例如：IShowMessages 与 IMessageShower 之类的东西。但是 - 情况并非总是如此。我在编写游戏对象时使用的接口包括：IOpenClosable 和 ILockable。 ICanBeOpenedAndClosed 和 ICanBeLocked 等替代方案会更加冗长。或者您可以简单地执行 IAmOpenClosable 和 IAmLockable - 但随后您将添加“Am”只是为了拟人化效果而没有真正的信息优势。如果传达相同数量的信息，我完全赞成尽量减少冗长。

【讨论】：

【解决方案4】：

IThinkItsATerribleIdea

【讨论】：

太糟糕了，最有趣的回应没有单独的投票。 ;)
+1 公共类手榴弹： IThinkItsATerribleIdea { public Grenade(){ throw new GoesAgainstTheGrainException(); }}
@Philip：给你：“用名词或名词短语或描述行为的形容词命名接口。” msdn.microsoft.com/en-us/library/8bc1fexb(VS.71).aspx
-1：非常没用的答案（不幸的是，这个笑话太老了，我无法忽略投票，尽管没用）
@Frerich：问题是“SO 的人是怎么想的？”我真的认为这是个坏主意。 IShowMessages、IHaveMessageParameters、ICanReadAndWriteStuffToAndFromFiles 或 IThinkItsATerribleIdea 都同样无用，因为它们传达其目的的可读性/清晰度低于更传统的等价物。

【解决方案5】：

只要试图实现的语义没有丢失并且简洁性没有受到不可挽回的损害（IDoLotsOfThingsWhichIncludesTheFollowingColonSpace...）。除了我自己之外，我通常不会介意其他人这样做。尽管如此，在很多情况下，简洁是最重要的，在这种情况下这是不可接受的。

【讨论】：

【解决方案6】：

在我看来，这种方法只会增加开发人员提出此类名称的负担，因为它将 I 整合为句子的一部分。例如，我没有发现 IDisposable 比 ICanBeDisposed 更难阅读。

【讨论】：

【解决方案7】：

当然，您应该始终选择人类可读的标识符。如：将它们传达的意思传达给那些不像你那样熟悉代码要解决的问题的人。

但是，使用长标识符不会使您的标识符更“可读”。对于任何经验丰富的程序员来说，'tmp' 传达的信息与 'temporaryVariable' 一样多。 'i' 与 'dummyCounter' 等也是如此。

在您的特定示例中，接口名称实际上很烦人，因为习惯于开发面向对象系统的人会将继承读取为“is a”。而且“SomeClass 是一个 IHaveMessageParameters”听起来很傻。

尝试改用 IMessagePrinter 和 IMessageParameterProvider。

【讨论】：

【解决方案8】：

使用简单易读的名称并不奇怪。但是使用I作为界面也代表第一人称I，好像它在谈论自己......有点不寻常，是的。

但最重要的是，无论对您有用，并且您和您的团队都能理解，都可以。你必须选择有效的方法。

【讨论】：

这就是我提到 C# 语法的原因，从历史上看，我来自 Windows C++\COM 背景，这种表示法已经被卡住了。我知道很多人不使用“I”语法...

【解决方案9】：

是的，这听起来是个好主意。

有什么选择？

代码应该是人类可读的。任何傻瓜都可以编写计算机可以理解的代码。困难的部分是编写人类可以理解的代码。

人类必须维护代码，因此尽可能易于维护是非常重要的——这包括代码应尽可能可读。

【讨论】：