私はパターンの設計に非常に慣れていないため、流暢なインターフェースと Builder パターンの違いに問題があります。
流暢なインターフェースの概念を理解しています。しかし、ビルダー パターンは少しわかりにくいです。Builder パターンで Director を使用する方法がわかりません。
Builder パターンと Fluent Interface を併用できますか? もしそうなら、Director とコンクリート ビルダーをどのように使用すればよいですか?
私の質問は、ビルダー パターンの利点に関するものではありません。しかし、この質問の目的は、ビルダー パターンと流暢なインターフェイスの関係を知ることです。
GoF から Builder の UML シーケンス図を編集します。
Fluent Interfaceはセマンティック ファサードです。それらを既存のコードの上に置いて、構文上のノイズを減らし、ユビキタス言語でコードが何をするかをより明確に表現します。これは、内部のドメイン固有言語を構築するときに使用されるパターンです。読みやすさについてです。
ディレクター/ビルダーは、何かの構築を調整します。つまり、ピザ焼き機を構築している場合、Director は、注文からピザまでのステップが適切なビルダーによって適切なデータを使用して適切な順序で実行されるようにします。検証と委任についてです。
ディレクタ/ビルダー パターンの上に流暢なインターフェイスを配置して、より流暢に読みやすくし、ドメインの概念を強調することができます (ビルドと委任の技術的なプロセスとは対照的です)。それはおそらく式ビルダーでしょう。
Fluent Interface は単なるMethod Chainingではないことを強調したいと思います。それはよくある誤解です。メソッドチェーンは Fluent Interface を実装するための 1 つのアプローチですが、セマンティックな性質が欠けているため、同じではありません。たとえば、これは Fluent Interface ではありません。
SomeObject.setFoo(1).setBar(2).setBaz(3);
上記は SomeObject について何も表現していません。これは、何らかのセマンティック モデルの上にあるファサードではありません。それはチェーンされたいくつかのメソッドです。Fluent Interface の例は、SQL クエリ ビルダーです。
SQLBuilder.select('foo').from('bar').where('foo = ?', 42).prepare();
その API の内部には、SQL ステートメントを作成するコードがあります。いくつかのオブジェクトが含まれている可能性があり、示されている呼び出しは、Select オブジェクトを作成し、その上でセッターを呼び出し、Condition オブジェクトを作成して Select オブジェクトに適用し、最後に Statement オブジェクトを返すことができます。しかし、それはすべて私たちから隠されています。これはまた、Fluent Interfaces の別の側面を浮き彫りにします: それらはSOLIDとDemeter の法則 に違反する可能性があります。しかし、これらの設計原則にうまく従うのはコード上のファサードであるため、違反を Fluent Interface にローカライズするため、それほど重要ではありません。