マジックナンバーとデータ抽象（kawasima）

核心的な主張

コードに転がるマジックナンバーやベタなステータス比較は、まだ名前を与えられていないドメインの概念が埋もれている目印である。

リファクタリングの段階

段階	内容	何が改善されるか
定数化	3 → MAX_RETRY	値に名前がつく
Enum 化	STATUS_ACTIVE = 1 など	同じ軸の改善・利用側に解釈が漏れる
データ抽象（真のゴール）	order.canCancel(), retryPolicy.isExhausted()	振る舞いの内側に値と判断を隠蔽する

データ抽象の原則（参考文献）

• Liskov & Zilles 1974、Parnas 1972 の情報隠蔽原則に基づく

• Arlo Belshee の命名 7 段階において、定数化はドメイン抽象（最終段階）に達していない中途段階

変更の局所化

アプローチ	局所化できる変更
定数化	値の変更のみ
データ抽象	値の変更 + 値の使い方（判定ロジック）の変更まで

よくある失敗パターン

• Constants.java のような定数集約ファイルは、共有コンテキストのない「アイデアの寄せ集め」

• Enum をドメインの外から直接比較する（order.status == Status.ACTIVE）のは抽象が漏れている状態

要点

• マジックナンバーはドメイン概念が命名されていないサイン

• 定数化→Enum は「値に名前をつける」段階で、真のデータ抽象ではない

• 振る舞いを持つオブジェクトとして抽象化すると変更の局所化が最大になる