タグ付けされた質問 「builder-pattern」

「ビルダー」パターンは「テレスコープコンストラクター」アンチパターンに対処することに制限されていますか、それとも不変オブジェクトの複雑な作成のより一般的な問題に対処すると言うことができますか？ StringBuilderクラスは、その名の単語「ビルダー」を持っているが、それは伸縮コンストラクタとは何の関係もありません、それは単に私たちは不変オブジェクトのコンストラクタに渡す必要があることを、すべてのデータを収集するのに役立ちます。 私には、答えは非常に明確な「はい」のように見えますが、このトピックについては意見の相違があるようです。 私はこの質問に答えていました：プログラマーSE：コンストラクターでの正当な「本物の仕事」？OPが複雑なツリーを含む（おそらく不変の）オブジェクトを作成したい場合、「ビルダー」パターンのアイデアがポップアップし、それを調査中に「StringBuilder」スタイルのオブジェクト作成と言われるこのQ＆Aを見つけましたではない私には明確ではない理由のために、「ビルダー」パターンの適用、：stackoverflowの-のStringBuilderとビルダパターン。（その質問に答えた人は、私が知る限り説得力のあるポイントを作ることができませんでした。）

31 design  design-patterns  builder-pattern 

Builderパターン（主にJava）の多くの実装を見てきました。それらはすべて、エンティティクラス（クラスとしましょうPerson）とビルダークラスを持っていますPersonBuilder。ビルダーはさまざまなフィールドを「スタック」し、new Person渡された引数とともにを返します。Personクラス自体にすべてのビルダーメソッドを配置するのではなく、明示的にビルダークラスが必要なのはなぜですか？ 例えば： class Person { private String name; private Integer age; public Person() { } Person withName(String name) { this.name = name; return this; } Person withAge(int age) { this.age = age; return this; } } 簡単に言えます Person john = new Person().withName("John"); なぜPersonBuilderクラスが必要なのですか？ 私が見る唯一の利点は、Personフィールドをとして宣言できることfinalです。したがって、不変性が保証されます。

31 java  design-patterns  builder-pattern 

私たちのコードベースは、私のような古いプログラマーと新しいプログラマーであり、均一性のために行われた方法ですぐにそれを行うことを学びます。私たちはどこかから始めなければならないと考えて、私は自分自身にそれとしてデータホルダークラスをリファクタリングしました： セッターメソッドを削除し、すべてのフィールドを作成しましたfinal（final公理的には "良い"です）。結局のところ、セッターはコンストラクターでのみ使用されていたため、副作用はありませんでした。 Builderクラスを導入しました コンストラクター（そもそもリファクタリングを促したもの）が約3行のコードにわたるため、Builderクラスが必要でした。それは持っている多くのパラメータを。 運が良ければ、チームメイトが別のモジュールで作業していて、たまたまセッターが必要でした。なぜなら、必要な値がフローのさまざまなポイントで利用可能になったからです。したがって、コードは次のようになりました。 public void foo(Bar bar){ //do stuff bar.setA(stuff); //do more stuff bar.setB(moreStuff); } セッターを取り除くことでフィールドが不変のままになることを可能にするため（以前に不変性についての不満を聞いたことがあります）、またビルダーはオブジェクトの作成をトランザクション可能にするため、代わりにビルダーを使用する必要があると主張しました。次の擬似コードをスケッチしました。 public void foo(Bar bar){ try{ bar.setA(a); //enter exception-throwing stuff bar.setB(b); }catch(){} } その例外が発生すると、barデータが破損しますが、ビルダーでは回避できます。 public Bar foo(){ Builder builder=new Builder(); try{ builder.setA(a); //dangerous stuff; builder.setB(b); //more dangerous stuff builder.setC(c); return builder.build(); }catch(){} …

22 design-patterns  teamwork  builder-pattern 

クラスに多くのパラメーター（たとえば4個以上）を持つコンストラクターがある場合は、おそらくコードの匂いであることがよく知られています。クラスがSRPを満たすかどうかを再検討する必要があります。 しかし、10個以上のパラメーターに依存するオブジェクトをビルドし、オブジェクトを作成し、最終的にBuilderパターンを使用してこれらすべてのパラメーターを設定するとどうなりますか？Person個人情報、仕事情報、友人情報、興味情報、教育情報などを含むタイプオブジェクトを作成するとします。これは既に良いことですが、どういうわけか同じ4つ以上のパラメーターを設定していますか？なぜこの2つのケースは同じと見なされないのですか？

21 design-patterns  constructors  builder-pattern 

私は最近、Code Reviewで私のJavaの回答を削除しました。 private Person(PersonBuilder builder) { やめる。赤旗。PersonBuilderはPersonを構築します。それは人について知っています。PersonクラスはPersonBuilderについて何も知らないはずです-それは単なる不変の型です。ここで、Aに依存するBに依存するAに依存する循環カップリングを作成しました。 Personはパラメータを取得するだけです。構築せずにPersonを作成するクライアントは、それを実行できる必要があります。 私は下票で平手打ちされ、それを（引用して）赤旗と言った、なぜ？ここでの実装は、Joshua Blochが彼の「Effective Java」本（アイテム＃2）で示したものと同じ形をしています。 したがって、Javaでビルダーパターンを実装する正しい方法は、ビルダーをネスト型にし（これはこの質問の目的ではありません）、製品を作成することです（ビルドされているオブジェクトのクラス）このように、ビルダーに依存します： private StreetMap(Builder builder) { // Required parameters origin = builder.origin; destination = builder.destination; // Optional parameters waterColor = builder.waterColor; landColor = builder.landColor; highTrafficColor = builder.highTrafficColor; mediumTrafficColor = builder.mediumTrafficColor; lowTrafficColor = builder.lowTrafficColor; } https://en.wikipedia.org/wiki/Builder_pattern#Java_example 同じBuilderパターンの同じWikipediaページには、C＃の実装が大きく異なります（そして、はるかに柔軟です）。 //Represents a product created …

20 java  design-patterns  coupling  builder-pattern 

名前付き引数とオプションの引数をサポートする言語を使用する場合、ビルダーパターンは実用的ではなくなりますか？ ビルダー： new Builder(requiredA, requiredB).setOptionalA("optional").Build(); オプション/名前付き引数： new Object(requiredA, requiredB, optionalA: "optional");

20 design-patterns  builder-pattern 

編集：この質問は理論的な問題を説明していることを指摘したいと思います。必須パラメーターにコンストラクター引数を使用できること、またはAPIが正しく使用されていない場合はランタイム例外をスローできることを認識しています。ただし、コンストラクター引数やランタイムチェックを必要としないソリューションを探しています。 次のCarようなインターフェースがあるとします。 public interface Car { public Engine getEngine(); // required public Transmission getTransmission(); // required public Stereo getStereo(); // optional } コメントが示唆するCarように、Engineとは必須ですTransmissionが、Stereoはオプションです。つまりbuild()、Carインスタンスが可能なビルダーは、ビルダーインスタンスにとの両方が既に与えられているbuild()場合にのみメソッドEngineをTransmission持つ必要があります。その方法は、型チェッカーが試みが作成することは、任意のコードコンパイルを拒否しますCarせずにインスタンスEngineまたはTransmission。 これには、ステップビルダーが必要です。通常、次のようなものを実装します。 public interface Car { public Engine getEngine(); // required public Transmission getTransmission(); // required public Stereo getStereo(); // optional public class Builder { public BuilderWithEngine engine(Engine …

10 design-patterns  builder-pattern 

JavaおよびC＃では、パラメーターを使用してコンストラクターを定義するか、オブジェクトの作成後に各プロパティを定義するか、ビルダー/流体インターフェイスパターンを使用して、初期化時に設定できるプロパティを持つオブジェクトを作成できます。ただし、C＃3ではオブジェクトとコレクションの初期化子が導入されたため、ビルダーパターンはほとんど役に立たなかった。イニシャライザのない言語では、ビルダーを実装して次のように使用できます。 Vehicle v = new Vehicle.Builder() .manufacturer("Toyota") .model("Camry") .year(1997) .colour(CarColours.Red) .addSpecialFeature(new Feature.CDPlayer()) .addSpecialFeature(new Feature.SeatWarmer(4)) .build(); 逆に、C＃では次のように記述できます。 var vehicle = new Vehicle { Manufacturer = "Toyota", Model = "Camry", Year = 1997, Colour = CarColours.Red, SpecialFeatures = new List<SpecialFeature> { new Feature.CDPlayer(), new Feature.SeatWarmer { Seats = 4 } } } …

10 c#  object-oriented  builder-pattern 

これは、別の質問に対するこの回答が動機です。 ビルダーパターン）、特に、オプションの初期化パラメータとの複合体の初期化を簡略化するために使用されます。しかし、相互に排他的な構成を適切に管理する方法がわかりません。 ここにImageクラスがあります。 Imageファイルまたはサイズから初期化できますが、両方から初期化することはできません。コンストラクタを使用してこの相互排除を強制することは、クラスが十分に単純な場合に明らかです。 public class Image { public Image(Size size, Thing stuff, int range) { // ... initialize empty with size } public Image(string filename, Thing stuff, int range) { // ... initialize from file } } Imageビルダーパターンが役立つように実際に十分に構成可能であると想定すると、突然これが可能になる可能性があります。 Image image = new ImageBuilder() .setStuff(stuff) .setRange(range) .setSize(size) // <---------- NOT …

9 design-patterns  object-oriented  builder-pattern 

多くの場合、（Javaでの）ビルダーパターンの実装は次のようになります。 public class Foo { private Foo(FooBuilder builder) { // get alle the parameters from the builder and apply them to this instance } public static class FooBuilder { // ... public Foo build() { return new Foo(this); // <- this part is what irritates me } } } ここにも例： …

8 design-patterns  builder-pattern