日々常々

ふつうのプログラマがあたりまえにしたいこと。

IntelliJ IDEAで複数のクラスをマージする

値オブジェクトなクラスを呼吸をするように作っていると「あれ、これ同じじゃ?」となることがたまにあります。 使用箇所が少なければ手作業でマージしてもいいのですが、多くの箇所で使っているクラスだと大変。 文字列の一括置換でやれなくはないんですが、正規表現力が試されますし、誤置換が怖いです。import文とかあるし、同じ名前を部分的に使っているクラスやメソッドを置換してしまうと困ったことになります。(こないだ事故った。)

そういう時、Inline Super Class(親クラスのインライン化)が使えます。

f:id:irof:20211021121346p:plain

例

ちょっと長いですが、全体を貼ります。試してみたいかたはどうぞ。

class OrderService {

    OrderNumber 新規注文(OrderDetail orderDetail) {
        // ... 何らかの処理
        OrderNumber orderNumber = new OrderNumber("dummy");

        return orderNumber;
    }

    Order 注文詳細(ReceiptNumber receiptNumber) {
        if (!receiptNumber.isValid()) {
            throw new IllegalArgumentException();
        }

        // ... 何らかの処理
        Order order = new Order(receiptNumber, new OrderDetail());

        return order;
    }

    BillingNumber 請求(OrderNumber orderNumber) {
        // ... 何らかの処理
        BillingNumber billingNumber = orderNumber.toBillingNumber();

        return billingNumber;
    }
}

/** 受付番号 */
class ReceiptNumber {
    String value;

    ReceiptNumber(String value) {
        this.value = value;
    }

    String value() {
        return value;
    }

    boolean isValid() {
        return !value.isBlank();
    }
}

/** 注文番号 */
class OrderNumber {
    String value;

    OrderNumber(String value) {
        this.value = value;
    }

    String value() {
        return value;
    }

    BillingNumber toBillingNumber() {
        // 何らかのルールに従って生成する
        return new BillingNumber();
    }
}

/** 注文 */
record Order(ReceiptNumber receiptNumber, OrderDetail orderDetail) {
}

/** 注文内容 */
class OrderDetail {
}

/** 請求番号 */
class BillingNumber {
}

これの「ReceiptNumber と OrderNumber が同じでよさそう」と気づいたとしましょう。(登場場面もメソッドも違うから違うでよさそうなんだけど、今回はクラスのマージの紹介なので目を瞑ってください。)

実行ステップ

  1. テストが通るのを確認する
  2. 片方でもう片方を継承する
  3. テストが通るのを確認する
  4. Inline Super Class... を実行する
  5. テストが通るのを確認する
  6. 気に入らないメソッドの並び順や変数名を直す
  7. テストが通るのを確認する
  8. コミットする

操作自体は1分かかりません。ファイル数によってはインライン化にそこそこかかるかもしれません。テストの実行時間は努力してください。

初期状態

f:id:irof:20211021143405p:plain

片方でもう片方を継承する

マージなんでどっちがどっちでも構いません。 寄せたい方があればそちらを子クラスにすればいいですが、どちらにせよマージ後に名前変更すればいいだけの話です。 extends して、コンストラクタで super 呼ぶようにして、フィールドを消す。

-class OrderNumber {
+class OrderNumber extends ReceiptNumber {

-    String value;
 
     OrderNumber(String value) {
-        this.value = value;
+        super(value);
     }

-    String value() {
-        return value;
-    }

この作業は手作業になります。なのでテスト必須。

フィールドが private だと使用しているメソッドがコンパイルエラーになりますが、一時的にprotectedにするとか、アクセサメソッドを介するなどで対応できます。

f:id:irof:20211021143447p:plain

Inline Super Class... を実行する

extends の後ろ(今回は ReceiptNumber)にカーソルを持って行って Inline Super Class... を実行します。 私はRefactor ThisにHotkeyを入れてるので冒頭の画像のようになりますが、コンテキストメニューからならこの辺です。(⌥⌘Nなんて覚えてません。なぜか指は勝手に使うけど。)

f:id:irof:20211021123405p:plain

選択ダイアログでは、クラスをマージしたいので親クラスに消えてもらう方を選びます。keepじゃなくremoveの方。

f:id:irof:20211021123201p:plain

結果、以下のような OrderNumber になります。

class OrderNumber {

    String value;

    OrderNumber(String value) {
        this.value = value;
    }

    BillingNumber toBillingNumber() {
        // 何らかのルールに従って生成する
        return new BillingNumber();
    }

    String value() {
        return value;
    }

    boolean isValid() {
        return !value.isBlank();
    }
}

ReceiptNumber にあったメンバが持ってこられてます。privateメソッドやstaticメソッドがあっても持ってきてくれます。

これに加え、ReceiptNumberを使用しているコードもすべてOrderNumberに置き換えられます。型の使用箇所で処理してくれるので、文字列置換とは安心感が段違いです。

super呼び出しがインライン化されるため、子クラスのコンストラクタはsuper呼び出し以外をしないこと。他の処理をいれていると挙動が変わることになります。また、同じメソッドが定義されていた場合(今回だと value() を削除しなかった場合)、警告ダイアログが出てきます。どうとでもなるので、いい感じにしましょう。

f:id:irof:20211021143719p:plain

一気に変わってますが、個別には以下になります。なおメンバのpush downはリファクタリングメニューから個別に実行できます。

f:id:irof:20211021144728p:plain

やりたいのは「使用クラスの変更」なんですが、これを安全に行うのが本稿の内容になります。それなりの規模で根底のドメインを変えると、数百ファイル同時に編集されたりします。手作業では面倒で不安。

これ書いた動機

型とIDEの機能を使えば素早く安定してコードをこねくり回せます。その一例。

値オブジェクトを作ると「クラスがたくさんになり過ぎて困るのでは」みたいなのがありますが、その困ることのひとつに「違うと思ってたけど実は同じだった」というのがあります。この時に時間と精神力を消費して必ず誤る手作業(酷い表現だ)や、祈りの文字列置換を行うのでは気が重いため、作ろうとした時に「違うように見えるけど本当は同じなのでは?」と穿ってみる必要が出てきます。

一塊のものを分けるより、分かれているものをくっつけるほうがよほど簡単です。

もちろん例外はあるけど。一塊のものを分離するのはなかなか機械的にはできません。いくつかできるテクニックはあります(それはまたそのうち……と言って書いてないのどんだけあるだろう)が、いつもできるわけではありません。 一方、分かれているものをくっつけるのはほぼほぼ機械的にできますし、機械的にできるものは今回のようにIDEで一発だったりします。

てことで、また知識が十分でない時は「なんか違うものっぽいなぁ」と感じたらじゃんじゃんクラスを作っていくといいと思います。同じかどうかを判断するのは後からでもできる。「同じと扱っていたものを後から分ける」より、「違うと思っていたものが実は同じだったからくっつける」の方が楽だと思います。

f:id:irof:20211021132551p:plain

ツイートのリンク。まぁなんだ、要はバランスですよ、はい。

おまけ: 簡単で不安定な別解

少々乱暴ですが、以下の方法もあります。

  1. 2つのクラスの内容を一致させる。(コピペ。)
  2. 片方のクラスをファイルごと削除する。(使用箇所があるとか警告されますが無視して実行。コンパイルエラーになる。)
  3. 残った方の名前を削除した方の名前に変換する。(リファクタリング機能を使用する。)

コンパイルエラー状態でのリファクタリング機能は精度が落ちるので推奨はしません。最近はだいぶいい感じに動きますが、安心して使えるとは言い難いです。 この手順では、2番目でファイルを削除しなかったら「ファイル名が一致する」とかで怒られます。

さらに派生で削除する代わりに参照先モジュールに持っていくことでコンパイルエラーを回避するとかもありますが、マルチモジュール構成でなければできませんし、大掛かりになるので他の事故要因も出てきます。どうしても必要な時にって感じですね。

蛇足: recordのとき

recordを使うと継承が使用できないので、素直にはできなくなります。現段階では一旦recordをclassに書き換えて上記の手順を実施、その後recordに戻す……かなぁと思ってます。IntelliJ IDEAでclassとrecordの変換は相互にできるので、これも別に手間じゃないかなって。

あわせてよみたい?

irof.hateblo.jp

ライブコーディング中に使ったIntelliJ IDEAの機能を適当に紹介してます。今回書いたのは意識して使う機能ですが、リンク先で挙げてるのはほんと無意識に使うレベルのもの。