LoginSignup
0
0

More than 3 years have passed since last update.

Effective Java(第3版) 項目2 多くのコンストラクタパラメータに直面したときにはビルダーを検討する

Posted at

インスタンスの生成に多数のパラメータ、特に多数のオプションのパラメータが必要な場合は、ビルダーを検討するべき、という内容です。

記載内容

メリット

  1. 多数のコンストラクタオーバーロードを用意するより、利用側のコードが分かりやすくなる
  2. オプションの項目を後からsetするような状況を避けることが出来る
  3. ビルダーが戻り値型の任意のサブタイプのインスタンスを返すことが出来る

デメリット

特に記載されていません

考察

メリットについて

ファクトリメソッドと同じく、不変クラスの生成に向いていると思います。
呼び出し側のコードが、他言語にある名前付きパラメータのようになるのも分かりやすいです。

ただ、呼び出し側のコードで、何番目のパラメータが何の項目を指定しているのかが分かりづらい、
というのは、IDEの補助があればさほど大きな問題にはならないかもしれません。

また、パラメータの数が多すぎる場合に、いくつかのパラメータをまとめたクラスを定義し、
そのインスタンスを渡すようにすれば解決できるかもしれません。

デメリットについて

記載されていませんが、ファクトリメソッドと同様に、

  1. サブクラスが作れない
  2. プログラマがインスタンスの生成方法を見つけるのが難しい

というデメリットは発生します。

また、ビルダークラス分のコード量が増える、というのはデメリットと思われます。

まとめ

本では「コンストラクタやstaticファクトリメソッドが多くのパラメータを持つクラスを設計する際には、Builderパターンは良い選択です」と記載されていますが、
実際にビルダーを導入するべきなのかは難しい判断だと思います。

ビルダー自体は決まりきったコードなので、実装は容易なのですが、
どの程度のパラメータ数なら導入するのか、
将来のパラメータ追加をどの程度考慮するべきなのか、
ビルダー分のコード量増加というデメリットとのバランスを考える必要が有ります。

一度publicコンストラクタを公開してしまえば、後からビルダーを導入することが難しくなる、
というのも判断を難しくしていると思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0