私は次の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();
これは、流暢なインターフェイスの典型的な問題です。setRead（）の方が自明であるという@Bozhoに同意しますが、流暢なインターフェイスの目的は、個々のメソッド呼び出しを読み取り可能にするのではなく、「文」全体を読み取り可能にすることです。
したがって、私はさらに一歩進んでいきます。どうですか：
somePermissions.readable().nonWritable().executable()
このトピックに関するMartinFowlerの投稿も参照してください。彼は次のように述べています。「このような流暢なAPIを構築すると、異常なAPIの習慣が生まれます」
set{Property}絶対に。メソッドが何をしているかを示します。あなたの財産がvisibleまたはencodingまたはと呼ばれていると想像してくださいalgorithm。使用しsetないことは意味がありません。
プロパティの名前とは異なる、よりわかりやすいアクション名を使用できます。例えば：
visible-> show(..)
encoding->> encode(..)
read- makeReadable(..)
name> giveName(..)（ "name"は動詞ですが、あいまいです）
set明らかに明快さを妨げます。それらは実際には豆のような方法ではないので、私はそれを落とすと言います。
また、ビルダーを製品から分離することをお勧めします。製品の不変性を優先します。
フラグがある場合は、メソッドのペアよりもブール値を使用する方がはるかに良いと思います。Javaライブラリは、この変更を1.0から1.1に変更しました。しかし、私はまだブール値が好きではありません。とには、それほど高いレベルの意味はありませtrueんfalse。enumsの方が優れています。さらに良いことに、（例のように）セットと見なすことができるものについて話している場合は、Set（おそらくとして実装されているEnumSet）を使用します。