デザインパターンのクリエーターパターンを詳しく解説

定義 (Baidu Encyclopedia より):
基本的な考え方は、「複雑なオブジェクト構築アルゴリズム」をその「コンポーネントとアセンブリ メソッド」から分離し、コンポーネント アルゴリズムとアセンブリ メソッドが独立して変更に対応できるようにすることです。再利用される 構築アルゴリズムは異なる表現を作成でき、異なる構築プロセスは同じコンポーネント アセンブリ メソッドを再利用できます

UML クラス図:

車はエンジンからリアビューまで多くの部品で構成されています。車を組み立ててユーザーに渡すのは明らかに非現実的です

たとえば、アウディが欲しい場合、上記の例で言えば、アウディを作りたいとディレクターに言います。 その後、Director は Audi に対応する Builder インターフェイス (ConcreteBuilder インスタンス) を見つけます。ConcreteBuilder は、Audi を構築するすべての部品と手順を知っています。 たとえば、最初に大きなフレームを構築し、次にエンジンを選択し、次に適切なタイヤを選択して、最後に をクリックします。バックミラー、これらの手順は buildPart プロセスです。つまり、これは非常に複雑なプロセスです

コンポーネント:

Builder: 製品オブジェクトの各コンポーネントの構造を標準化するための抽象インターフェイスを提供します。このインターフェイスは、複合オブジェクトのどの部分を作成するかを指定します。特定のオブジェクト コンポーネントの作成は含まれません。
上記の例に相当するのは、車やエンジンなどのさまざまな部品の組み立てです。
ConcreteBuilder: ビルダー インターフェイスを実装して、さまざまなビジネス ロジックの複雑なオブジェクトの各部分を具体的に作成します。 構築プロセスが完了したら、製品の例を提供します。
上記に対応するのは、アウディビルダーを組み立て、農業機械のホイールを段階的に追加することです...
ディレクター: 特定のビルダーを呼び出して、複雑なオブジェクトのさまざまな部分を作成します。ディレクターには、特定の製品情報は含まれません。オブジェクトが完全に、または何らかの順序で作成されることを保証する責任があります。
「ディレクター」という言葉はディレクターを意味し、彼の責任は非常に明確です: スケジュール設定。上の例では、プロデューサーとしての私のアイデアがアウディを使用することである場合、ディレクターはそれを行うように ConcreteBuilder に通知します。
Product: 作成される複雑なオブジェクト。

長所と短所:

長所:
疎結合: 複雑なプロダクトの作成ステップをさまざまなメソッドに分解することで、作成プロセスがより明確になり、複雑なオブジェクトの生成プロセスをより正確に制御できるようになります。
再利用性の向上: 製品の構築と組み立てと分解により、建築製品は再利用可能になります。

短所:
ビルダー モードで作成された製品には一般に多くの共通点があり、コンポーネントが類似しています。製品間の差異が大きい場合、ビルダー モードの使用には適さないため、その使用範囲は制限されます。一定の制限に。
製品の内部変更が複雑な場合、そのような変更を実装するために多くの特定のビルダー クラスを定義する必要が生じ、システムが非常に大きくなる可能性があります。

以上がデザインパターンのクリエーターパターンを詳しく解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。