モチベーション
のソフトウェアシステムでは、時々 、通常、特定のアルゴリズムでサブオブジェクトの様々な部分から成る作業を作成するための「複合オブジェクト」直面、需要の変化に、この複雑な主題の様々な部分は、しばしば劇的な変化に直面しますが、それらを組み合わせたアルゴリズムは比較的安定しています。
この変化に対応するには？どのように「パッケージ機構」ことにより、ニーズの変化として変化していない「安定した構造アルゴリズム」のシステムを維持し、「複雑なオブジェクトのさまざまな部分」の変化を分離するために提供するには？
定義
と同じ構築処理（安定剤）は、複雑なオブジェクトの異なる表現（変化）を作成できるように、構築物は、その相分離を表します。
- 「デザインパターン」のGoF
構造
例
class House{
//....
};
//Builder
class HouseBuilder {
public:
House* GetResult(){
return pHouse;
}
virtual ~HouseBuilder(){}
protected:
House* pHouse;
virtual void BuildPart1()=0;
virtual void BuildPart2()=0;
virtual void BuildPart3()=0;
virtual void BuildPart4()=0;
virtual void BuildPart5()=0;
};
class StoneHouse: public House{
};
//ConcreteBuilder
class StoneHouseBuilder: public HouseBuilder{
protected:
virtual void BuildPart1(){
//pHouse->Part1 = ...;
}
virtual void BuildPart2(){
}
virtual void BuildPart3(){
}
virtual void BuildPart4(){
}
virtual void BuildPart5(){
}
};
//Director
class HouseDirector{
public:
HouseBuilder* pHouseBuilder;
HouseDirector(HouseBuilder* pHouseBuilder){
this->pHouseBuilder=pHouseBuilder;
}
House* Construct(){
pHouseBuilder->BuildPart1();
for (int i = 0; i < 4; i++){
pHouseBuilder->BuildPart2();
}
bool flag=pHouseBuilder->BuildPart3();
if(flag){
pHouseBuilder->BuildPart4();
}
pHouseBuilder->BuildPart5();
return pHouseBuilder->GetResult();
}
};
要約
1.、複数の部品から構成される複雑なオブジェクトであるモデルの複雑なオブジェクトを作成するためのビルダーおよびメンバーを作成し、それぞれ監督を表すそれぞれビルダークラスとクラス開いています。上記方法でカプセル化された監督を有する最終複合オブジェクトの構成は（作られるこれらの部材からなる複雑なオブジェクト）ビルダーインターフェイス部材が作成され、すなわち、どのように製品部材に最終組立を担当監督。だから、デカップリングのBuilderパターンの設計と実装をしましょう。
2.パッケージの変更点、 -ビルダモード主として「の複雑さに応じて
頻繁に需要の様々な部分として変化します」。欠点は、「ステップバイステップのビルドに対応することは困難であるということである
需要変動アルゴリズム」。