接口命名：前缀“ Can-”与后缀“ -Able”

通常使用“ -able”作为接口的后缀，例如

可序列化可打印可枚举可饮用可射击可旋转

我以为'Can-'可能会更好，因为它可能更具描述性。是的，它比较罗y，给接口名称增加了干扰。特别地，可以使用被动动词。

例如，“ 1可射击”表示该物体能够射击（枪支可以实现这一目标），或者它可以被射击（目标板可以实现这一目标）。使用“ Can-”前缀，前者将为“ CanShoot”，后者将为“ CanBeShotAt”或“ CanShootAt”。

例如2文档“ CanBePrinted”和打印机“ CanPrint”

或者，我们应该坚持使用“ -Able”并让文档提供上下文吗？

任何意见。

也许您想要Is-able？

.Net的一些示例：

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

似乎没有统一的标准。顺其自然。

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

编辑：如前所述，问题是关于接口，而不是属性。

在那种情况下，我找不到任何名为Can-的接口。接口往往总是使用-able。我同意这个术语。方法可能要求a ISerializable object或a作为参数IPrintable document。询问a ICanBeSerialized object或a ICanBePrinted document非常尴尬。

另一方面，我建议您仅调用该接口 IPrinter。您的方法将要求IPrinter device。

大声阅读下面的方法签名。（就我个人而言，我认为“ I”前缀是无声的。）它读得好吗？听起来对吗？

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

在语法上，“ canFoobar”是一个谓词，而“ Foobarable”是一个形容词或名词（通常在API上下文中为名词）。

还要注意细微的区别：-able暗指它所应用的名词的被动角色，也就是说，如果Something是Foobarable的，那么它可能会被其他事物愚弄；can-表示活动角色，也就是说，如果Something canFoobar，则可以对其他东西进行foobar。或者，从另一个角度来看：如果A可以使B愚弄，则A.canFoobar()和B is Foobarable。

就OOP的表达能力而言，我将谓词与方法或属性相关联，而名词则是类或接口。所以：

instance.canFoobar();

class Something implements Foobarable { ... }

我个人会坚持使用-able版本。这是我的原因：大多数（全部？）图形编辑器都会根据您键入的内容建议标识符。尽管它们中的一些“足够聪明”，也可以在标识符内搜索，但有些仍然只是提供标识符的搜索开始。

为了加快输入速度，您希望通过尽可能少的击键来缩短建议的标识符列表。标识符以相同的开头开头的字符越多，例如“ ICan-”，则您必须键入的字符越多。

如果您认为这不是您的问题，那就很好了，我建议您使用其他条件来选择命名约定。在某些情况下，例如在我们的团队中，我们希望使用标识符，以使击键次数尽可能少。

除此之外，我建议使用命名约定，以使您的代码对从事该项目的人员最易理解。在团队中进行对话。这样就没有对与错。只是有效的约定和无效的约定。

不要忘记，良好的重构工具可让您根据需要多次重命名。因此，很容易尝试使用不同的方法。

显然，前缀和后缀几乎是针对不同类型的动作或更确切地说是不同方向的选择。

但是，由于多种原因，当前的用法和首选项可能会不一致。

执行动作的对象：
CanShoot - > 据芽（在）什么
CanFly - > 它飞
CanChange - > 它改变

对对象执行操作：
可读-> 您可以读取它
可写-> 您可以将其写入（
打印）-> 您可以将其打印

尽管这可能不是规则，甚至不一定是逻辑的，但它有助于采用约定并保持变量命名中使用的一致性。

我认为您可能希望区分能力和许可。虽然Serializable并CanSerialize暗示的东西是能够被序列化，也有权限的问题（或者是磁盘空间不足），你可能需要考虑MaySerialize。任其发展~able就无需区分can和may。

在子类化/实现接口时，我认为经验法则是您应该能够说“ B是A”（其中B实现A）。听起来不对：

A Document是一个CanBePrinted

但这听起来似乎正确（或至少更好）：

A Document是一个Printable

我认为语法上和约定上的Xable都更适合接口的名称，而IsX，CanX，DoesX则更适合属性的名称。

从MSDN：

“请使用肯定性短语（CanSeek而不是CantSeek）来命名布尔属性。可选地，您也可以在Is，Can或Has之前为布尔属性添加前缀，但只能在增加值的地方使用。” http://msdn.microsoft.com/zh-CN/library/ms229012.aspx

在我看来，“-able”变体要比您建议的“ CanDoSomething”可读性强得多，后者强加了更多的驼峰。

在Scala中，*Able用于接口，但Can*用于类型类模式。本质上，要能够调用某些方法，范围内必须存在某种类型的隐式值。此类型的名称有时以开头Can。