コンストラクタのメソッド利用で注意すること

Java入門ではさらっと以下のように書いた、コンストラクタでインスタンスメソッドを実行することについて掘り下げてみます。

コンストラクタからインスタンスメソッドを使用することは可能ですが、避けたほうが無難です。 コンストラクタの実行中はインスタンス自体が構築中のため、初期化が完了していない状態でメソッドが実行されることになります。

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

文章だけで伝えるのはなかなか難しいものだとも思いますし、 本に書いたのに実際にこの問題を見た時に即解決できなくて悔しかった ので、 突っ込んでしっかり書くことにしました。くそう。。。

簡単なサンプルコード

コンストラクタでのインスタンスメソッド呼び出しが問題を起こすコードは、以下のようになります。

/* このコードは動作しません */
class Hoge {
    final String str;

    Hoge () {
        invoke();
        this.str = "HOGERA";
    }

    void invoke() {
        System.out.println(str.length());
    }
}

new Hoge()とかするとNullPointerExceptionです。

Exception in thread "main" java.lang.NullPointerException
  at blog.constructor.Hoge.invoke
  at blog.constructor.Hoge.<init>

このくらい短いコードなら、流石にやらないでしょうが、 コンストラクタとinvokeメソッドの間に数百行の隔たりがあればどうでしょう？ フィールドはfinalだし、うっかり使ってしまうかもしれません。 作成時は問題がなかったとしても、不具合改修などでこの手の問題が起こしてしまったとしても、 その開発者を不注意だと責め立てることは、私には出来そうもありません。（自分もやっちゃうだろうし。）

少し複雑にしたサンプルコード

さらに問題を複雑にすると、冒頭のように1クラスに完結している形では問題なく動作しているにもかかわらず、 継承すると問題が起こるパターンも考えられます。擬似的なコードは次のようなものになります。

/* このコードは動作しません */
abstract class Parent {

    final String arg;

    Parent(String arg) {
        init();
        this.arg = arg;
    }

    abstract void init();
}

class Child extends Parent {

    Child(String arg) {
        super(arg);
    }

    @Override
    void init() {
        System.out.println(arg.toUpperCase(Locale.ROOT));
    }
}

new Child("xxx")とかでNullPointerExceptionになります。

Exception in thread "main" java.lang.NullPointerException
  at blog.constructor.Child.init
  at blog.constructor.Parent.<init>
  at blog.constructor.Child.<init>

少し説明落ち着いてコードを追えば、コンストラクタ引数がフィールドに格納される前に、 そのフィールドを参照しているので、フィールド型のデフォルト値（参照型なのでnullになる）となっているだけです。

しかし、このNullPointerExceptionに遭遇すると、おそらく「finalフィールドなのになぜ値が入っていないんだ？」となります。 コンストラクタの引数がnullになっていないかや、どこかで受け渡し損ねてないかなどを確認するかもしれません。 デバッガでinitメソッドにブレイクポイントを置いてみたりするかもしれません。いくら見ても、事実が示すようにフィールドはnullです。

継承階層が深くなると、メソッドの呼び出しタイミングがわからなくなっていきます。 全てのコードの詳細を把握することは困難ですし、全ての人にそれを求めるべきではありません。 上記のようにinitメソッドが拡張ポイントのように扱われていると、フレームワークがコンストラクタの後に呼びだす初期化処理と想像しても、不思議ではないでしょう。

さらに複雑にした（略

もっと複雑に、もっとわかりにくくすることは可能です。もっともっと。 でも、書いても楽しくないので箇条書きで許してください。

• コンストラクタで呼ばれるメソッド（上記だとinit）で例外が発生せず、そこから呼び出したメソッドで発生する。
  • スタックトレースが深くなり、コンストラクタを示す<init>が出ないので問題の検出が遅れます。
• コンストラクタで呼ばれるメソッドで生成されたインスタンスにフィールドのデフォルト値が設定される。
  • nullで即例外が発生すればいいのですが、生成されたインスタンスに意図せぬ値が入ったまましばらく経ち、別のタイミングで不正な状態で実行されることになります。
  • このパターンでさらに問題を起こすクラスのインスタンス生成箇所が多かったりすると、原因の特定難度はさらに上がります。
• 対象がプリミティブ型
  • 参照型であればNullPointerExceptionが発生することで助かります（そう、例外が発生すればまだ助かるのです。少なくとも不正な更新を行ったりしてデータを壊す可能性は下がります。ぬるぽはいい子です。）が、プリミティブ型ならおそらくデフォルト値でそのまますんなり動いてしまいます。
• フィールド参照ではなく、そのフィールドを使用する別のメソッドを使用する。
• フィールドがfinalでなく、頻繁に書きかわる。

……こんなのデバッグしたくないです。

どうすれば？

Java入門ではこんな感じで書きました。

もしインスタンスメソッドを実行する必要があるのならば、privateメソッドやfinalメソッドのような 拡張されないメソッドにできないかを検討し、対象のメソッド内で他のメソッドを呼び出さないように気をつけましょう。

書いたことは書いたままなのですが、まだ他にも考えられます。

提供側として、どうすればよいか

もし実装クラスで拡張することを想定したインスタンスメソッドを、コンストラクタでどうしても実行したいのならば、どうすれば良いかを考えてみます。 まず、そのメソッドが何をするための拡張ポイントであり、どういうタイミングで実行されるかなど ドキュメントをしっかり書いてください 。 そして、一切のメンバを使用禁止にします。これは三階層以上の継承がある場合、二階層目のコンストラクタで初期化されるフィールドやそれを使用するメソッドが正常に動作しないタイミングで呼ばれてしまうためであり、そのことを具象化しようとしているクラスでの検知が困難だからです。 その上で、メソッドで使用する値は 全て メソッドの引数で渡しましょう。

これでようやく、気をつけて使っていれば大丈夫な可能性のある物体になるかもしれません。 しかし、間違った使い方のできるものは、間違った使い方をされるものです。 要約すると「やらせるな」ということです。考え直しましょう、真面目に。真剣に。悪いこと言わないから。

利用側として、どうすればよいか

さて、利用側の視点でどうすればいいかには触れてきませんでした。

これは いくら利用者が気をつけても、安全に設計できていないものを、安全に使用することはできない からです。 単純なケースであればテストコードなどで比較的容易に検出はできるのですが、「さらに複雑にした（略」あたりで書いているものは辛いです。

フレームワークやライブラリのコードを読むことは推奨したいのですが、必須ではありません。 特に仕事ではコストは確保されないでしょうし、そういうスキルも求められないでしょう。 なので、不具合に気づいたら修正依頼をするか、迂回するか、パッチを当てるくらいでしょうかね。

あとがき

Java入門 第2章「クラスを理解する」の最後の方に書いた コンストラクタでは注意してメソッドを使用する を掘り下げてみました。 コードある方がわかりやすいかな。どうだろう。どっちでもわかりにくいよ、と言われたらごめんなさいとしか言いようがない。 しかし全部このノリで書いたらページいくらあっても……難しい。

出版されてから1年経ちますが、内容はまだ古くなってません。 そのなかで、こんな感じの内容を入門と言い張ってます。入門だよ、うん。

• 「Javaエンジニア養成読本」が出るのです - 日々常々)