Builder パターンは、私にとってその存在が特に明確ではないパターンのグループに属していますが、これが明らかに冗長であることに注目します。ジェネレーティブ デザイン パターンのグループに属します。複雑なオブジェクトを作成するための単純なインターフェースを実装するために使用されます。
適用性
インターフェースの簡素化。 多数の引数を持つコンストラクターでのオブジェクトの作成が容易になり、コードの可読性が客観的に向上します。
ビルダーを使用しない C++ の例:
auto weapon = new Weapon(“Claws”);
monster->weapon = weapon;
auto health = new MonsterHealth(100);
monster->health = health;
Пример со строителем на C++:
.addWeapon(“Claws”)
.addHealth(100)
.build();
Однако в языках поддерживающих именованные аргументы (named arguments), необходимость использовать именно для этого случая отпадает.
Пример на Swift с использованием named arguments:
let monster = Monster(weapon: “Claws”, health: 100)
不変性。 ビルダーを使用すると、最終アセンブリ段階まで作成されたオブジェクトを確実にカプセル化できます。ここで、パターンを使用することで作業環境の激しい変動から身を守ることができるかどうかを慎重に考える必要があります。おそらく、開発チーム内にカプセル化を使用する文化が欠如しているため、パターンを使用しても何も得られません。 .
オブジェクト作成のさまざまな段階でのコンポーネントとの対話。 また、このパターンを使用すると、システムの他のコンポーネントと対話するときに、オブジェクトを段階的に作成することができます。おそらくこれは非常に便利です (?)
批判
もちろん、プロジェクト内でこのパターンの広範な使用を確立する価値があるかどうかを*慎重に*考える必要があります。最新の構文と高度な IDE を備えた言語では、コードの読みやすさの向上という点で、ビルダーを使用する必要がなくなります (名前付き引数に関するポイントを参照)。
GoF 本が出版された 1994 年にこのパターンを使用すべきだったでしょうか?おそらくその通りですが、当時のオープン ソース コード ベースから判断すると、それを使用している人はほとんどいませんでした。
ソース
https://refactoring.guru/ru/design-patterns/builder