研究ノート@EffectiveJava
記事の内容は、Joshua Bloch-Effective Java（3rd）-2018.chmという本からのものです。
第2章
オブジェクトの作成と登録解除
項目1は、コンストラクターの代わりに静的ファクトリメソッドの使用を検討します
静的ファクトリメソッドは、デザインパターンのファクトリメソッドパターンと同じではありません
public static Boolean valueOf(boolean b) {
return b ? Boolean.TRUE : Boolean.FALSE;
}
利点1：静的ファクトリメソッドはコンストラクタとは異なります-名前があります
適切な名前の静的ファクトリメソッドを使用すると、コードが読みやすくなります
利点2：静的ファクトリメソッドはコンストラクターとは異なります-呼び出されるたびに新しいオブジェクトを作成する必要はありません
冗長なオブジェクトを作成しないでください
利点3：静的ファクトリメソッドはコンストラクタとは異なります-返されたオブジェクトのサブクラスを返すことができます
Java 8以降、インターフェースに静的メソッドを含めることができないという制限がなくなりました。
利点4：静的ファクトリメソッドが入力パラメータメソッドとして使用され、返されるオブジェクトタイプは呼び出しによって変更される可能性があります
戻り値の型はサブクラスで柔軟に制御できます
利点5：静的ファクトリメソッドクラスにメソッドが含まれている場合、返されるオブジェクトタイプは存在する必要はありません。
この柔軟な静的ファクトリメソッドは、Javaデータベース接続API（JDBC）などのサービスプロバイダーフレームワークの基礎を形成します。
- - - - -境界線 - - - - -
短所1：静的ファクトリメソッドのみを提供することの主な制限は、サブクラス化（継承）できないクラスにパブリックまたは保護されたコンストラクターがないことです。
短所2：プログラマーにとって見つけるのが難しい
したがって、次の命名規則に従って注意を引くことができます
from-パラメータを受け取り、対応するタイプのインスタンスを返す変換メソッド
Date d = Date.from(instant);
of-複数のパラメータを取り、これらのタイプのインスタンスを含む集計メソッドを返します
Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);
valueOf-fromおよびofメソッドのより詳細な代替
BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);
instanceまたはgetInstance-パラメータで記述されたインスタンスを返しますが、同じ値を持つことはできません
StackWalker luke = StackWalker.getInstance(options);
createまたはnewInstance-instanceやgetInstanceなどの新しいインスタンスを作成または作成しますが、このメソッドは、呼び出されるたびに新しいインスタンスが返されることを保証します
Object newArray = Array.newInstance(classObject, arrayLen);
getType-getInstanceに似ていますが、ファクトリメソッドは別のクラスにあり、タイプはファクトリメソッドによって返されるオブジェクトのタイプです。
FileStore fs = Files.getFileStore(path);
newType-newInstanceに似ていますが、ファクトリメソッドは別のクラスにあり、タイプはファクトリメソッドによって返されるオブジェクトのタイプです。
BufferedReader br = Files.newBufferedReader(path);
type-getTypeおよびnewTypeの簡潔な代替
List<Complaint> litany = Collections.list(legacyLitany);
要するに、静的ファクトリメソッドとパブリックコンストラクタの両方に用途があり、それらの相対的な利点を理解することは価値があります。通常、静的ファクトリが望ましいので、条件付きリフレクションを避け、最初に静的ファクトリメソッドを考慮せずにパブリックコンストラクタを使用します
項目2は、多くの建設パラメータに直面したときに発電機モードを検討します
静的ファクトリメソッドとコンストラクターの両方に制限があります。それらは、多数のオプションパラメーターに適切にスケーリングできません。
従来の方法
// Telescoping constructor pattern - does not scale well!
public class NutritionFacts {
private final int servingSize; // (mL) required
private final int servings; // (per container) required
private final int calories; // (per serving) optional
private final int fat; // (g/serving) optional
private final int sodium; // (mg/serving) optional
private final int carbohydrate; // (g/serving) optional
public NutritionFacts(int servingSize, int servings) {
this(servingSize, servings, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories) {
this(servingSize, servings, calories, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories, int fat) {
this(servingSize, servings, calories, fat, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories, int fat, int sodium) {
this(servingSize, servings, calories, fat, sodium, 0);
}
public NutritionFacts(int servingSize, int servings,
int calories, int fat, int sodium, int carbohydrate) {
this.servingSize = servingSize;
this.servings = servings;
this.calories = calories;
this.fat = fat;
this.sodium = sodium;
this.carbohydrate = carbohydrate;
}
}
//当你想创造实例，你使用包含所有你需要的参数最少的构造函数
NutritionFacts cocaCola = new NutritionFacts(240, 8, 100, 0, 35, 27);
通常、この種のコンストラクターは、不要なパラメーターを使用して呼び出されますが、とにかくパラメーターを渡す必要があります。上記の例では、値0をfatに渡します。
つまり、オーバーラップコンストラクターモードは実行可能ですが、多くのパラメーター、クライアント（APIメソッドを実装するクライアントクライアントと呼ばれる）のコード
を書くことは難しく、それを読むことはより困難です。多くの選択されたパラメーターがあります。2番目の選択肢はJavaBeansモードです。パラメータなしのコンストラクターを呼び出すこの関数はオブジェクトを作成してから、setterメソッドを呼び出して必要なパラメーターを設定します。各パラメーターは便利です。
// JavaBeans Pattern - allows inconsistency, mandates mutability
public class NutritionFacts {
// Parameters initialized to default values (if any)
private int servingSize = -1; // Required; no default value
private int servings = -1; // Required; no default value
private int calories = 0;
private int fat = 0;
private int sodium = 0;
private int carbohydrate = 0;
public NutritionFacts() { }
// Setters
public void setServingSize(int val) { servingSize = val; }
public void setServings(int val) { servings = val; }
public void setCalories(int val) { calories = val; }
public void setFat(int val) { fat = val; }
public void setSodium(int val) { sodium = val; }
public void setCarbohydrate(int val) { carbohydrate = val; }
}
//这种模式没有重叠构造函数模式的缺点，创建实例很容易
//即使有点冗长，也很容易阅读生成的代码
NutritionFacts cocaCola = new NutritionFacts();
cocaCola.setServingSize(240);
cocaCola.setServings(8);
cocaCola.setCalories(100);
cocaCola.setSodium(35);
cocaCola.setCarbohydrate(27);
残念ながら、JavaBeansモデルには独自の重大な欠点があります。構築は複数の呼び出しに分割されるため、JavaBeanは構築プロセス中に一貫性のない状態になる可能性があります。
このクラスは、コンストラクターパラメータの有効性をチェックするだけでは一貫性を強制できません。
関連する欠点は、JavaBeansモデルがクラスを不変にする可能性を排除し、スレッドセーフを確保するためにプログラマーによる追加の努力を必要とすることです。
幸い、安全なJavaBeansパターンと重複するコンストラクターパターンを組み合わせた3番目の選択肢があります。これ
はビルダーパターンです[ビルダーパターン]
クライアントは必要なオブジェクトを直接生成しませんが、必要なすべてのパラメーターを使用します。コンストラクター（または静的ファクトリメソッド）を作成し、ビルダーオブジェクトを取得します。
次に、クライアントはビルダーオブジェクトでセッターのようなメソッドを呼び出して、必要な各オプションパラメーターを設定します。
最後に、クライアントはパラメーターなしのコンストラクターメソッドを呼び出してオブジェクトを生成します。オブジェクトは通常不変です。
ジェネレーターは通常、ビルドするクラスの静的メンバークラスです。
例：
// Builder Pattern
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
private final int fat;
private final int sodium;
private final int carbohydrate;
public static class Builder {
// Required parameters
private final int servingSize;
private final int servings;
// Optional parameters - initialized to default values
private int calories = 0;
private int fat = 0;
private int sodium = 0;
private int carbohydrate = 0;
public Builder(int servingSize, int servings) {
this.servingSize = servingSize;
this.servings = servings;
}
public Builder calories(int val)
{ calories = val; return this; }
public Builder fat(int val)
{ fat = val; return this; }
public Builder sodium(int val)
{ sodium = val; return this; }
public Builder carbohydrate(int val)
{ carbohydrate = val; return this; }
public NutritionFacts build() {
return new NutritionFacts(this);
}
}
private NutritionFacts(Builder builder) {
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
fat = builder.fat;
sodium = builder.sodium;
carbohydrate = builder.carbohydrate;
}
}
//NutritionFacts类是不可变的，所有参数的默认值都在一个地方。
//生成器的setter方法返回生成器本身，以便可以链接调用，从而生成流畅的API。
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
.calories(100).sodium(35).carbohydrate(27).build();
ジェネレーターパターンはクラス階層に非常に適しています。
ジェネレーターの並列階層を使用して、各ジェネレーターは対応するクラスにネストされます。抽象クラスには抽象ジェネレーターがあり、エンティティクラスにはエンティティジェネレーターがあります。
たとえば、抽象クラスについて考えてみます。階層はさまざまな種類のピザを表します
// Builder pattern for class hierarchies
public abstract class Pizza {
public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
final Set<Topping> toppings;
abstract static class Builder<T extends Builder<T>> {
EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);
public T addTopping(Topping topping) {
toppings.add(Objects.requireNonNull(topping));
return self();
}
abstract Pizza build();
// Subclasses must override this method to return "this"
protected abstract T self();
}
Pizza(Builder<?> builder) {
toppings = builder.toppings.clone(); // See Item 50
}
}
簡潔にするために、以下に示すサンプルクライアントコードは、列挙型定数の静的インポートを想定しています。
NyPizza pizza = new NyPizza.Builder(SMALL).addTopping(SAUSAGE).addTopping(ONION).build();
Calzone calzone = new Calzone.Builder().addTopping(HAM).sauceInside().build();
ジェネレータモードは非常に柔軟です。1つのジェネレーターを再利用して、複数のオブジェクトを作成できます。ジェネレーターのパラメーターは、ビルドメソッドを呼び出して作成されたオブジェクトを多様化する間に調整できます。ジェネレータは、オブジェクトの作成時に、オブジェクトが作成されるたびにインクリメントされるシリアル番号など、特定のフィールドに自動的に入力できます。
ジェネレータモードにも欠点があります。オブジェクトを作成するには、最初にそのジェネレーターを作成する必要があります。このジェネレーターの作成コストは実際には目立たない可能性がありますが、パフォーマンスが重要な状況では問題になる可能性があります。
また、ジェネレーターモードは、オーバーラップするコンストラクターモードよりも冗長であるため、十分なパラメーターがある場合に限ります。たとえば、4つ以上のパラメーターを使用する価値がある場合にのみ使用されます。
つまり、コンストラクターまたは静的ファクトリメソッドデザインクラスに複数のパラメーターがある場合、特に多くのパラメーターがオプションである場合、またはタイプが同じ場合、ジェネレータモードは良い選択です。重複するコンストラクターパターンと比較して、ジェネレーターはクライアントコードの読み取りと書き込みが簡単であり、ジェネレーターはJavaBeansよりも安全です。