テンプレートパターンは、派生クラスでステップを変更できる基本クラスのアルゴリズムを提供します。Builderパターンでは、concrete Builderは、Directorクラスから呼び出される製品を構築するためのメソッドを公開します。
これらのパターンを使用する目的には違いがあることを理解しています。テンプレートパターンは、テンプレート内の1つ以上のステップを変更する動作パターンですが、ビルダーパターンは作成パターンです。
上記の違いとは別に、他に違いはありますか？
テンプレートパターンのベーステンプレートとして機能するビルダーパターンのディレクターではありません。具体的なビルダーは、代替可能なステップを使用して、テンプレートパターンの派生クラスのように動作していますか？
誰かが明確にしてください。ありがとうございました。
テンプレートメソッドは、実際には、各サブクラスが定義する必要のあるいくつかのメソッドを定義するための単なる方法です。
ビルダーパターンは、より複雑なオブジェクトを構築するために使用されます。
さまざまなサーブ（自動車ブランド）モデルを構築したいとします。各モデルには、異なるエンジン、ライトなどがあります。
テンプレートメソッドパターンを使用する場合は、車の単一の組み合わせごとに1つのクラスを作成するか、いくつかの厄介な継承階層を使用する必要がありました。これらのメソッドの多くには、重複したコードも含まれています。
ビルドパターンを使用すると、代わりにさまざまなパーツを取り、それらを組み合わせて完成車にすることができます。したがって、必要に応じてすべてのモデルでエンジンを再利用でき、車の各部分をカスタマイズすることもできます。
同じ質問がとても面白いと思いました。
サーブ車の例は興味深いものですが、「Gang of Four」（デザインパターン）のビルダーパターンの説明に準拠していません。
「ギャング・オブ・フォー」という用語を使用します。
ギャングオブフォーでは、サーブの例を呼び出すたびにコンクリートビルダーをブレンドすることはできませんが、aDirector->Construct()興味深いのは私にとって本当に質問に答えることはできません。
私はいくつか見ます：
ビルダー階層からのdirectorオブジェクトの分離は、重要な違いです。テンプレートファクトリでは、一般化されたフローを具体化するメソッドとオーバーライドされたメソッドの両方が同じクラスのメンバーです。これにより、Directorオブジェクトのみにアクセスする場合、クライアントコードがそのようなメソッドと接触する可能性が低くなるため、Builderパターンはプロセスの内部ステージをカプセル化するのに適しています。Builderパターンでは、Builder階層から完全に独立したアセンブリプロセスの定式化も可能であり、必要に応じてBuilderインスタンスをより柔軟に置き換えることができます。たとえば、directorインスタンスが手元にあれば、コンクリートビルダーを動的に置き換えるたびに、製品の複数の表現を簡単に構築できます。
さらに、継承によってDirectorオブジェクトを詳しく説明したい場合は、階層を増やさずに行うことができます。たとえば、最終的な構築の前に時間を節約するために構築する明示的なプロセスがある場合があります。Directorオブジェクトをサブクラス化するか、それ自体で「テンプレートメソッド」を使用して、具体的なビルダーを再実装することなく、継承によってカスタマイズすることができます。
しかし、これにより、「テンプレートファクトリ」に密接に関連する別のパターンである「戦略」パターンを検討することになります。
ストラテジーはテンプレートファクトリと非常によく似ていますが、2つの明確な違いがあります。それは、コンテキストオブジェクトをストラテジー階層から分離しすぎて、実行時に単一の問題インスタンスのアルゴリズムを切り替えることができるようにすることです。もう1つの違いは、これらの例は、戦略の呼び出しが必ずしも「テンプレートメソッド」のように複雑または構造化されたプロセスを伴うとは限らないことを示唆しているように見えることです。
しかし、別のポイントに到達するために、Builderの類似物としてここに持ってきます-「Strategy」がそのクラス構造でBuilderと並列である場合、「TemplateMethod」への並列作成パターンは「FactoryMethod」である必要があります。これは、名前だけでなく、興味深いことに、「ファクトリメソッド」と「テンプレートメソッド」の両方の章で、ほぼ同じ例（ドキュメントを編集するためのアプリケーション）を使用していることは明らかです。
したがって、作成パターンと動作パターンの違いは何であるかという問題に立ち入ることなく、ビルダーメソッドとファクトリメソッドはどちらも基本的にそれぞれ戦略とテンプレートメソッドの特定のケースと改良であると考える傾向があります。
したがって、質問は次のようになります-BuilderとTemplate Factoryの間に違いが見られない場合は、次の質問に答えてみてください。
システムのその特定の部分について、どのような視点を好むでしょうか。それは「行動」なのか「創造」なのか？と
一方では、強力なカプセル化、またはビルダーインスタンスの動的な置換、展開、または微調整が必要ですか、それとも、作成プロセスまたはテンプレートメソッドを中心に複雑さ（継承、構成などによる）が進化することを期待していますか？これらの質問のいずれかに対する答えがビルダー/戦略構造に当てはまる場合。それ以外の場合は、XXメソッドパターンで関係または動作の単純な多形を使用します。
始める前に、私のすべての答えに対する私の普遍的な線は次のとおりです。「どの言語のプログラミング概念でも、3つの方法で理解する必要があります。（a）設計の観点から（b）ランタイムの観点から（c）メモリの観点から。
（a）に基づいてansを与えるpplは（b）に同意しない可能性があり、その逆もあります（または、明確な定義を汚染するために循環的な説明を提供する人もいます）。ピザビルダー、レストランビルダー、自動車ビルダー、またはUIテンプレート、ワークフローテンプレートは、エンタープライズプロジェクトでビルダー/テンプレートパターンを実装するように求められた場合、意味がありません（これらのパターンは、自分自身を定義するにはあまり成熟していない可能性があります）。失敗の理由は、オブジェクトを4つのステップでビルドする必要があることがわかっている場合、空からインスタンス化を開始し、directorを使用してステップごとに1つずつ入力する理由です。ステップ3を望まない場合、またはステップ2で非常に多くの例外が発生した場合はどうなりますか？代わりに、4つのステップすべてが完了したときに最終オブジェクトを作成します（これは私のキャリアを通じて正確に発生します。■ビルダーパターンが開発者に採用されない理由）。ここで、pplは、asynの動作が必要な分散システムで議論する可能性があり、Builderが役立ちます。しかし、その場合でも、onreadystatechange == 4に依存して、builderObjをインスタンス化します。だから私たちはビルダーを使うべきではありませんか？私見の答えは「いいえ」です。
私の理解は.netにあり、ControllerBuilder、SqlConnectionStringBuilder、UriBuilderがあります。すべてがControllerFactory、Sql、UriFactoryをカスタマイズしています。次に、私のメインプログラムは、これらのファクトリを使用して、Controllers、ConnStrings、Uriesを生成できます。では、ビルダーパターンは工場出荷時のセットアップのカスタマイズ用ですか？工場出荷時のセットアップのカスタマイズが必要ですか？おそらく決して; 代わりに、私が行う最善の方法は、4つの非同期メソッドを作成し、それらをステップ2のパラメーターでチェーンすることです（2番目のチェーンのステップ3のパラメーターで...）。どのようなabtテンプレートパターン（asp.netワークフローテンプレートまたはjQueryテンプレートまたは既定のテンプレート）。私にとってはどちらも同じですが、ビルダーと比較すると、テンプレートは本質的により厳格であり（ほとんどすべてが修正され、特定のtmpltを定義するために変更されるプロパティはほとんどありません）、テンプレートが定義されるとファクトリになります。いつビルダーパターンを使用しますか？; しかし、それは本当ではありませんbcozは、上記の.net ControllerBuilder、sql、uriシナリオと「FactoryofFactory」の概念に似ています。これは、多くの設計原則（SRP、LSP、不適切なカプセル化）に反します。これらの2つについての私の完全な執筆が、初心者から上級者まで役立つことを願っています。
私はこれら2つの用途と違いを特定した良い記事を読みました。