我Permissions在 Java 中有一个类，其方法流利，如下所示：
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)
set{Property}在传达意图方面比仅仅 {property} 更好。但是，由于您的示例是简单的布尔属性，因此更好的流畅接口可能是：
somePermissions.AllowRead().DenyWrite().AllowExecute();
这是流畅界面的经典问题。虽然我同意@Bozho 的说法，即 setRead() 更易于解释，但流畅接口的目标是使整个“句子”可读，而不是使单个方法调用可读。
因此，我会更进一步。怎么样：
somePermissions.readable().nonWritable().executable()
另见 Martin Fowler 的帖子关于此主题他说：“像这样构建流畅的 API 会导致一些不寻常的 API 习惯”
set{Property}确实。它告诉方法正在做什么。想象一下您的属性被称为visibleorencoding或algorithm。不使用set没有任何意义。
您可以使用与属性名称不同的更具描述性的操作名称。例如：
visible-> show(..)
encoding-> encode(..)
read> makeReadable(..)
name-> giveName(..)（“名称”是动词，但有歧义）
显然会set干扰清晰度。它们不是真正的豆类方法，所以我说放弃它。
我还建议将构建器与产品分开。更喜欢产品的不变性。
如果您有标志，我认为使用布尔值而不是成对的方法要好得多。Java 库进行了从 1.0 到 1.1 的更改。但是，我仍然不喜欢布尔值。true和中没有太多更高层次的含义false。enums更好。更好的是，如果您正在谈论可以被视为集合的东西（如示例中所示），则使用Set（可能实现为EnumSet）。