「StringBuilder」はBuilderデザインパターンのアプリケーションですか？

「ビルダー」パターンは「テレスコープコンストラクター」アンチパターンに対処することに制限されていますか、それとも不変オブジェクトの複雑な作成のより一般的な問題に対処すると言うことができますか？

StringBuilderクラスは、その名の単語「ビルダー」を持っているが、それは伸縮コンストラクタとは何の関係もありません、それは単に私たちは不変オブジェクトのコンストラクタに渡す必要があることを、すべてのデータを収集するのに役立ちます。

私には、答えは非常に明確な「はい」のように見えますが、このトピックについては意見の相違があるようです。

私はこの質問に答えていました：プログラマーSE：コンストラクターでの正当な「本物の仕事」？OPが複雑なツリーを含む（おそらく不変の）オブジェクトを作成したい場合、「ビルダー」パターンのアイデアがポップアップし、それを調査中に「StringBuilder」スタイルのオブジェクト作成と言われるこのQ＆Aを見つけましたではない私には明確ではない理由のために、「ビルダー」パターンの適用、：stackoverflowの-のStringBuilderとビルダパターン。（その質問に答えた人は、私が知る限り説得力のあるポイントを作ることができませんでした。）

A StringBuilderはBuilderパターンに似ていますが、このデザインパターンのGoF記述とはあまり共有しません。デザインパターンの元のポイントは

同じ構築プロセスで異なる表現を作成できるように、複雑なオブジェクトの構築をその表現から分離します。

— Gamma、Helm、Johnson、VlissidesによるDesign Patternsから。

（注：「複雑な」とは、主に「複数の部分で構成される」ことを意味し、必ずしも「複雑な」または「難しい」とは限りません）

ここでは、「異なる表現」が重要です。たとえば、この構築プロセスを想定すると：

interface ArticleBuilder {
  void addTitle(String title);
  void addParagraph(String paragraph);
}

void createArticle(ArticeBuilder articleBuilder) {
  articleBuilder.addTitle("Is String Builder an application of ...");
  articleBuilder.addParagraph("Is the Builder Pattern restricted...");
  articleBuilder.addParagraph("The StringBuilder class ...");
}

提供される具体的な実装に応じて、a HtmlDocumentまたはa TexDocumentまたはa になる可能性MarkdownDocumentがあります。

class HtmlDocumentBuilder implements ArticleBuilder {
  ...
  HtmlDocument getResult();
}

HtmlDocumentBuilder b = new HtmlDocumentBuilder();
createArticle(b);
HtmlDocument dom = b.getResult();

そのため、Builderパターンの中心点の1つはポリモーフィズムです。Design Patternsブックでは、このパターンをAbstract Factoryと比較しています。

Abstract Factoryは、複雑なオブジェクトを構築できるという点でBuilderと似ています。主な違いは、Builderパターンが段階的に複雑なオブジェクトの構築に焦点を合わせていることです。[…] Builderは最終ステップとして製品を返しますが、Abstract Factoryに関する限り、製品はすぐに返されます。

— Gamma、Helm、Johnson、VlissidesによるDesign Patternsから。

この段階的な側面は、Builderパターンのより一般的な側面になっているため、一般的な用語では、Builderパターンは次のように理解されます。

オブジェクトの構築を複数のステップに分割します。これにより、これらの機能をサポートしていない言語でも、名前付き引数またはオプションのパラメーターを使用できます。

ウィキペディアでは、次のようなパターンを定義しています。

ビルダーパターンは、オブジェクト作成ソフトウェアの設計パターンです。ポリファクトリを有効にすることを目的とした抽象ファクトリパターンやファクトリメソッドパターンとは異なり、ビルダーパターンの目的は、テレスコープコンストラクタアンチパターン^{[要出典]の}解決策を見つけることです。[…]

ビルダーパターンには別の利点があります。フラットデータ（htmlコード、SQLクエリ、X.509証明書など）を含むオブジェクト、つまり簡単に編集できないデータに使用できます。このタイプのデータは、ステップごとに編集することはできません。一度に編集する必要があります。このようなオブジェクトを構築する最良の方法は、ビルダークラスを使用することです。^{[引用が必要]}

-からBuilderパターン上のWikipediaの様々なコントリビュータによる、。

このように、この名前がどのパターンを指しているのかについての真の共通理解はなく、いくつかの点で異なる定義が互いに矛盾することさえあります（たとえば、ビルダーのポリモーフィズムの関連性について）。

StringBuilderパターンのさまざまな解釈での唯一の共通の特性は、製品が一度に作成されるのではなく、段階的に作成されることです。デザインパターンのGoF定義の厳密な読み取りには適合しませんが、デザインパターンはコミュニケーションを容易にするための順応性のある概念であることに注意してください。StringBuilderJavaの構造の主な理由は、不変なものではあるが、ビルダーパターンの例を呼び出し続けることです。不変の文字列が存在する場合のパフォーマンスの連結ですが、興味深いオブジェクト指向のデザインはありません。