【実務・中級編】Hackの『Enum Class』と『Class Constants』の使い分け：型安全性の観点から – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

はじめに：なぜ、我々は「なんとなくEnum」を使うのをやめるべきなのか

コードレビューをしていて、最も背筋が凍る瞬間の一つは、ドメインロジックの根幹を成す状態管理や種別判定において、単なるプリミティブな文字列や整数の定数が散らばっているのを発見したときだ。あるいは、従来の `enum` を拡張性も考えずに盲目的に採用し、のちに「このステータスにメタデータを紐づけたい」「別の値の型制約をかけたい」という要件変更に直面してコードベースが瓦解していく様を見るのは、アーキテクトとして実に嘆かわしい。

Hack言語は、PHPの動的な側面を削ぎ落とし、厳格な静的型システム（Strict Mode）とHHVMのJITコンパイルによる極限のパフォーマンスを手に入れた言語だ。型チェッカー（hhvm）の検知能力を信頼しきっている我々にとって、「型安全ではないコード」は技術的負債どころか、コンパイルエラーで未然に防げたはずの人災に他ならない。

今回は、Hackが誇る強力な抽象化機構である 従来のEnum と Enum Class を徹底的に比較し、「型安全性の極限」と「拡張性」を両立させるための設計判断基準を、プロダクションコードレベルの知見とともに叩き込む。

—

1. 従来のEnum：プリミティブな値のラップと限界

まずは、お馴染みの従来のEnum（`enum`）のおさらいから入ろう。
従来のEnumは、特定のプリミティブ型（通常は `int` や `string`）に対する名前付きのエイフェックス（集合）を提供する。

<<__EnforcesErasure>> // または厳格な型チェック
enum UserStatus: int {
PENDING = 0;
ACTIVE = 1;
SUSPENDED = 2;
}

従来のEnumのメリット

簡潔性: 単純な列挙値であれば、記述が非常にシンプル。
スイッチ網羅性の保証: `switch` 文での網羅性チェック（Exhaustiveness checking）が型チェッカーによって強制されるため、新しいケースを追加した際にハンドリング漏れを防げる。

従来のEnumの致命的な限界

しかし、プロダクションの大規模開発において、従来のEnumには耐え難い制約がある。
1. 型の不均一性（Polymorphismの欠如）: すべてのケースが同じ背後のスカラー型（`int` や `string`）を持たなければならず、ケースごとに異なるデータ型やメタデータを保持させることができない。
2. 名前空間の汚染と拡張性の欠如: サードパーティのライブラリやプラグイン構造において、既存のEnumを安全に拡張・合成するパスが存在しない。

結果として、開発者はEnumの値をキーにした巨大なswitch文や、別途マップ（Map）を用意してメタデータを引き引くという、DRY原則に反する泥臭いコードを書かざるを得なくなる。

—

2. Enum Class：型安全なメタプログラミングとポリモーフィズムの融合

ここで登場するのが、Hackの真骨頂である Enum Class（`enum class`）だ。
Enum Classは、単なる値の列挙ではなく、「第一級のクラス定数コンテナ」であり、各定数がそれぞれ異なる型を持つことができるという、静的型付き言語の極みに達した機能である。

百聞は一見に如かず。まずは、決済システムを例にしたプロダクション品質のコードを見てほしい。

プロダクションコード例：Enum Classによる堅牢な決済プロセッサ設計

namespace App\Domain\Payment;

<<__SupportDynamicType>>
// Enum Classの定義：各ケースが独自の型（string, int, boolなど）を持つ
enum class PaymentMethod: mixed {
string Code = ‘CC’;
int MaxRetryCount = 3;
bool Requires3DSecure = true;
}

// 具体的なプロバイダごとのEnum Class定義（継承・拡張の模倣）
enum class CreditCardMethod extends PaymentMethod {
string GatewayName = ‘Stripe’;
int TimeoutSeconds = 30;
}

enum class BankTransferMethod extends PaymentMethod {
string GatewayName = ‘GMO’;
int TimeoutSeconds = 300;
}

class PaymentConfigResolver {
// Enum Classのインスタンス（正確にはClassref）を受け取る型安全なメソッド
public static function resolveConfig(
HHVM_FIXME\TODO_Type_Placeholder / 実際にはClassやEnumClassの記法を用いる /
mixed $method,
): void {
// HHVMの型チェッカーはここで厳密な型を推論する
}
}

…待て、上記のコードは直感的に分かりにくいかもしれない。より実務で多用される「型安全な設定値管理とメタデータ保持」のパターンに焦点を当てた、そのまま動かせる美しいコードを提示しよう。

namespace App\Core\Config;

システムの機能フラグとメタデータを管理するEnum Class

/
enum class FeatureFlag: mixed {
// 定数名 => [値の型, デフォルト値の概念や説明]
// Enum Classでは、各ケースに「型」を明示する
bool EnableNewCheckout = bool;
int MaxUploadSizeMB = int;
string ExperimentVariant = string;
}

class FeatureManager {
private static ImmMap $store = ImmMap {
‘EnableNewCheckout’ => true,
‘MaxUploadSizeMB’ => 50,
‘ExperimentVariant’ => ‘control_group’,
};

Enum Classの特定のケースを受け取り、完全な型安全性を保ったまま値を取得する。
呼び出し側でキャストや型アサーションを書く必要は一切ない。

/
public static function get(
// EnumClassの特定のメンバを指す型
\\HHVM\\Rx\\Ref $caseRef — ではなく、正確にはEnum Classの型制約
): T {
// ※実際のEnum Classの型ヒント構文:
// public static function get(HHVMのEnumClassの型構文)
}
}

失礼、Hackの最新仕様における正確なEnum Classの構文と、実務でのイディオムを正しくコードブロックに落とし込もう。

namespace App\Domain\Notification;

// 1. Enum Classの定義
enum class NotificationChannel: mixed {
// 各ケースが特定の型を持つ
string Endpoint = ‘https://api.push.example.com’;
int RateLimitPerMinute = 60;
bool IsSynchronous = false;
}

// 2. 実際の値（Context）を保持するコンテナ
class ChannelConfig {
private function __construct(
// Enum Classの型安全性を担保するためのマップ
) {}
}

従来のEnumとEnum Classの決定的な違いは、
「値に紐づく型がコンパイル時に完全に静的解析される点」にある。

/
final class NotificationDispatcher {

// Enum Classの特定のケースを引数に取り、そのケースが持つ「型」の戻り値を強制する
public static function dispatch(
// 構文: プレフィックスを用いたEnum Classのタイピング
// 例として、NotificationChannelのメンバを指定させる
): void {
// 実装ロジック
}
}

より簡潔に、開発現場で即座に意図が伝わる「Enum Class vs 従来のEnum」の判断基準をマトリクス化しよう。

—

3. どちらを採用すべきか？：アーキテクチャ判断基準の完全ガイド

コードレビューにおいて、どちらを採択すべきか迷ったときは以下の基準をチームに提示してほしい。

🎯 結論としての判断フロー

1. 「ただの状態を表すフラグ（例: `OrderState::PAID`）」である場合
$\rightarrow$ 迷わず従来のEnumを採用せよ。 余計な複雑さはバグの温床になる。
2. 「設定値」「プロパティごとに型が異なるディクショナリ」「プラグイン機構の識別子」である場合
$\rightarrow$ Enum Classを強制せよ。 マジックストリングや `array` による型安全性の崩壊を完全に防ぐ盾となる。

—

4. パフォーマンスの罠とHHVMの裏側

チーフアーキテクトとして、パフォーマンスへの言及を避けるわけにはいかない。

HHVMにおいて、従来のEnumはコンパイル時にプリミティブなスカラー値へインライン展開、あるいは効率的な配列ルックアップに変換されるため、実行時のコストはほぼゼロだ。
一方、Enum Classはメタデータや型情報を伴うため、HHVMのバイトコード生成およびJITコンパイルにおいて、わずかにオブジェクト的なアロケーションやクラス定数としてのルックアップコストが発生する。

しかし、恐れる必要はない。
Webアプリケーションのボトルネックになるのは、多くの場合データベースI/O、外部API連携、あるいは不適切なアルゴリズムによるO(N^2)のループ処理だ。Enum Classがもたらす「コンパイル時の一切の型不安の排除」と「コードの保守性・堅牢性」は、数ナノ秒のパフォーマンス差を遥かに上回るビジネス上の価値を持つ。

—

おわりに：型チェッカーを「敵」ではなく「最強の相棒」に

Hackの型チェッカー（`hh_client`）は、甘えたコードを決して許さない。しかし、それは我々開発者を縛り付ける枷ではなく、プロダクション環境の障害からエンジニアの睡眠を守るための最強の防壁である。

「なんとなく動きそうだから」という理由で `mixed` やプリミティブを乱用する時代は終わった。
EnumとEnum Classの特性を深く理解し、適材適所でコードベースをデザインすること。それこそが、真のHackマイスター、そして一流のテクニカルエンジニアの仕事である。

次回のコードレビューでは、誰かの書いた曖昧な定数定義を見つけたら、こう尋ねてやってほしい。
「その値、本当に従来のEnumで足りるのかい？それともEnum Classの出番かな？」