具有流畅接口的方法名称
我有一个 Java 中的 Permissions 类，其方法如下所示：
somePermissions.setRead(true).setWrite(false).setExecute(true)
问题是，我是否应该将这些方法命名为 set{Property} 还是仅命名为 {property }。后者看起来像这样：
somePermissions.read(true).write(false).execute(true)
如果我单独查看这些方法，我会期望 read 读取一些内容，但另一方面，它更接近于像 Scala 中那样具有命名参数的意图：
Permission(read=true, write=false, execute=true)
I have a Permissions class in Java with methods in fluent style like this:
somePermissions.setRead(true).setWrite(false).setExecute(true)
The question is, whether I should name these methods set{Property} or only {property}. The latter would look like this:
somePermissions.read(true).write(false).execute(true)
If I look at these methods separately I would expect that read reads something, but on the other hand it is closer to the intention to have something like named paramaters like in Scala:
Permission(read=true, write=false, execute=true)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
set{Property}比仅使用 {property} 更能传达意图。然而，由于您的示例是简单的布尔属性，因此更好的流畅接口可能是：set{Property}is better than just {property} for conveying intent. However since your examples are simple boolean properties, an even better fluent interfance might be:这是流畅界面的一个经典问题。虽然我同意 @Bozho 的观点，即 setRead() 更不言自明，但流畅接口的目标是使整个“句子”可读，而不是使单个方法调用可读。
因此，我会更进一步。怎么样：
另请参阅 Martin Fowler 关于此主题的帖子。他说：“构建这样一个流畅的 API 会导致一些不寻常的 API 习惯”
This is a classic problem with fluent interfaces. While I agree with @Bozho that setRead() is more self explanatory, the objective in fluent interfaces is to make the whole "sentence" readable as opposed to making individual method calls readable.
Thus, I would go a step further. How about:
See also Martin Fowler's post about this topic. He says: "Building a fluent API like this leads to some unusual API habit"
明确设置{Property}。它告诉我们该方法正在做什么。想象一下您的属性被称为visible或encoding或algorithm。不使用set没有任何意义。您可以使用更具描述性的操作名称，该名称与属性名称不同。例如：
可见->显示(..)编码->编码(..)阅读>makeReadable(..)名称->giveName(..)（“name”是动词，但有歧义）set{Property}definitely. It tells what the method is doing. Imagine your property is calledvisibleorencodingoralgorithm. Not usingsetwon't make any sense.You can use more descriptive action names, which differ from the name of the property. For example:
visible->show(..)encoding->encode(..)read>makeReadable(..)name->giveName(..)("name" is a verb, but is ambiguous)set显然会干扰清晰度。它们并不是真正像豆子一样的方法，所以我建议放弃它。我还建议将构建器与产品分开。更喜欢产品的不变性。
如果你有标志，我认为使用布尔值而不是成对的方法要好得多。 Java 库将这一更改从 1.0 更改为 1.1。但是，我仍然不喜欢布尔值。
true和false没有太多更高层次的含义。enum更好。更好的是，如果您正在谈论可以被视为集合的东西（如示例中所示），则使用Set（可能实现为EnumSet）。The
setclearly interferes with clarity. They aren't really beans-like method, so I say drop it.I would also suggest separating the builder from the product. Prefer immutability in the product.
If you have flags, I think it much better to use booleans rather than pairs of methods. The Java library made this change going from 1.0 to 1.1. However, I still don't like booleans. There is not much higher-level meaning in
trueandfalse.enums are better. Better yet, if you are talking about something which can be considered a set (as in the example), then useSet(probably implemented asEnumSet).