Java Generics Hell - new T()

Java Generics Hell アドベントカレンダー 24日目。

読者の推奨スキルとしてはOCJP Silverぐらいを想定している。

今回はJavaジェネリクスでは型変数を用いてnew T()できないけど特に問題ないという話。

コンストラクタの形

コンストラクタは、その内部でthisが使えるしインスタンスフィールドへのアクセスもインスタンスメソッドへのアクセスも出来る。そこからするとインスタンススコープのメソッドのように見えるが、インスタンスに所属しているわけではない。


インスタンスメソッドを呼び出すにはインスタンスを指定するか、自分のインスタンスのメソッド呼び出しでthis.を省略できる、というシチュエーションでなくてはならない。逆に言えば通常のclassのnewはインスタンスなしで呼び出せるわけで、所属としてはclassのstaticに相当する。クラス名を指定する必要があるが、インスタンスを指定する必要はない、という独特のポジションである。


なので、継承を用いてinterfaceや親クラスによってコンストラクタの引数の形を規定することは出来ない。通常の継承埒外にいるわけである。コンストラクタはリスコフの置換原則の範囲外で、親クラスのコンストラクタと同様に子クラスのコンストラクタが呼べる必要はない。


こうした前提を踏まえると、型変数のような任意の型に対して、統一的なnewをしたいというのはJavaの型システムの範疇で考えると無理であるし、無茶な要求と言える。Javaあたりの世代のプログラム言語ではコンストラクタの引数がどのようなものか、指定することが出来ないし、指定したければ継承の範囲を超えた別のプログラミングパラダイムが必要になる。

デフォルトコンストラク

さて、そんなわけで汎用にコンストラクタの形状を定めるというのは無理で、どうしてもやりたければ、インスタンスを生成するクラスというものを用意するという迂遠なやり方をする必要がある。迂遠というか面倒くさいわけだが、こうした生成を行うクラスを別途用意する(ビルダークラスとかファクトリークラスという呼ばれ方をする)ことで対処できるといえば出来る問題である。いわゆるボイラープレートというやつで、定型句がわさわさ出てきて煩わしいという話はあるにせよ、だ。


しかし、特定のシチュエーションでは決まったコンストラクタの型をしているという前提を置くことが、ある程度妥当性を持つことがある。デフォルトコンストラクタである。

インスタンスの生成を行うメソッド

デフォルトコンストラクタとは要するに引数なしのコンストラクタで、単なるデータを保持するようなクラスの場合、概ねデフォルトコンストラクタを持つという前提を想定してよいケースがある。例えばO/Rマッパーのようなケースで、所定の型のデフォルトコンストラクタでインスタンスを作ってリフレクションでデータを詰めて返したい、そのメソッドがジェネリクスで具象型を指定したい、というわけである。

public class ORMapper {
	public <T> T select(String query) { ... } // これでは生成できない
}

この場合、Javaでやるなら先に挙げたようにビルダークラスを使う必要がある。そして、Java8以降を前提とするならば、ビルダークラスはラムダ式ないしメソッド参照でよい。引数にjava.util.function.Supplier<T>を用いよう。

public class ORMapper {
	public <T> T select(Supplier<T> builder, String query) {
		T ret = builder.get();
		// (略) 詰め込む処理
		return ret;
	}
}

こうした場合、呼び出し側は

ORMapper mapper = new ORMapper();
Hoge hoge = mapper.select(Hoge::new, "select * from hoge");

といった具合である。Java 10 以降であれば変数宣言時の型推論の導入が検討されている。Java10以降の環境であれば次のように書けるだろう。

ORMapper mapper = new ORMapper();
var hoge = mapper.select(Hoge::new, "select * from hoge");

C#の場合

さて、引き合いによく出されるC#では実行時にバインドされた型変数の型が引き回される。そして、new制約というデフォルトコンストラクタを持つことを型変数の制約とする特殊機能を使って(型クラスのような汎用機能ではないので過渡期の対処法だと思っておいた方が良いと思う)型変数でのnewを実現している。

https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/new-constraint

class ItemFactory<T> where T : new()
{
    public T GetNewItem()
    {
        return new T();
    }
}

ここでさっきのJavaのORMapperの例をC#にしてみると

public class ORMapper {
	public T Select<T>(String query) where T : new()
	{
		T ret = new T();
		// (略) 詰め込む処理
		return ret;
	}  
}

といった形になるだろう(筆者はC#は不案内なので誤りがあればご指摘願いたい)
この時、呼び出し側は

ORMapper mapper = new ORMapper();
var hoge = mapper.select<Hoge>("select * from hoge");

といった形になるだろう。
Java版(変数宣言時の型推論あり)と比較してみよう。

ORMapper mapper = new ORMapper();
var hoge = mapper.select(Hoge::new, "select * from hoge");

違いとしては、C#側ではメソッドスコープの型変数に対するバインドを明記する必要があり、代わりにnew制約を使うので引数にビルダークラスを取らなくて良い。Java側ではメソッドスコープの型変数は型推論で済ませる代わりにnew制約がないため引数にHoge::newを渡す必要がある。概ね、Hogeの位置が変わる程度で大差がない。

まとめ

  • new制約が便利に見えるが、言うほど劇的な利便性が得られるわけでもない
  • Javaでnew制約の代わりにTから実行時の型をとってリフレクションでnewInstance()しようというのは筋の悪いアプローチ
  • 筋の悪いアプローチをしようとして出来ないからといってイレイジャに八つ当たりするのは見当違いではないか

イレイジャのせいにする言説もしばしば見かけるが、いささか見当違いと言えるだろう。何を問題視しているか冷静に検討したいところだ。