状態の「ゆらぎ」を撲滅せよ：Hackにおける不変性（Immutability）の究極的活用術
HackのHHVMランタイムで最も恐ろしいバグは、メモリの深層で発生する「予期せぬ状態変化」だ。特に非同期処理や複雑なサービス層において、あるコンポーネントが書き換えたはずのないデータが書き換わっている……そんな悪夢を見たことはないだろうか。
今回は、Hackの強力な武器である`readonly`プロパティと不変コレクションを駆使し、バグの温床を根絶する設計指針を授ける。これは単なる規約ではなく、型チェッカーを「守護神」へと変えるための戦略だ。
—
1. なぜ「可変性（Mutability）」は悪か
実務において、共有されたオブジェクトのプロパティを外部から変更可能にする設計は、時限爆弾を埋め込んでいるのと同じだ。
// 悪い例：可変性に依存した設計
class UserProfile {
public string $name; // 誰でも書き換え可能
public function __construct(public string $email) {}
}
function update(UserProfile $user): void {
// どこかの誰かが突然 $user->name を書き換える
$user->name = ‘Hacked!’;
}
このコードでは、`update` 関数を呼び出した側は、自分の持っている `$user` がいつ破壊されるかを知る術がない。これが大規模システムでは追跡不能なバグの元凶となる。
—
2. `readonly` プロパティによる強制的な不変性
Hackの `readonly` 修飾子は、単なる「値の固定」ではない。HHVMのJIT最適化エンジンに、その値がライフサイクルを通じて不変であることを宣言し、型チェッカーに違反を即座に弾かせるための強力な契約だ。
実践的パターン：不変データクラス
<<__ConsistentConstruct>>
final class UserSession {
// コンストラクタ以外での書き込みを型レベルで封殺する
public function __construct(
public readonly int $userId,
public readonly string $token,
public readonly DateTimeImmutable $createdAt,
) {}
}
このクラスのインスタンスは、生成された瞬間にその状態が確定する。これ以降、誰かが `$session->token = ‘…’` と書こうものなら、型チェッカーが即座にエラーを吐き、デプロイ前に事故を防ぐ。
—
3. 不変コレクションを用いた「副作用のない」データ管理
オブジェクトだけでなく、配列（`vec`, `dict`, `keyset`）の扱いも重要だ。Hackの標準的な `vec` や `dict` は、実はデフォルトで非常に安全だが、さらに踏み込んで「意図しない変更」を排除するために、メソッドの境界では常にこれらを意識する必要がある。
安全な状態更新のイディオム：`with` パターン
不変オブジェクトを更新したい場合、破壊的変更ではなく「新しいインスタンスを生成する」のが鉄則だ。
final class Config {
public function __construct(
public readonly dict
) {}
// 状態を変更するのではなく、新しいConfigを返す
public function withSetting(string $key, string $value): this {
$newSettings = dict($this->settings);
$newSettings[$key] = $value;
return new self($newSettings);
}
}
// 活用例
$config = new Config(dict[‘theme’ => ‘dark’]);
$newConfig = $config->withSetting(‘theme’, ‘light’);
// 元の $config は絶対に汚染されない
invariant($config[‘theme’] === ‘dark’, ‘不変性が担保されている’);
このアプローチの利点は、「状態の履歴」をトレースしやすく、デバッグが極めて容易になることだ。
—
4. パフォーマンスの真実：不変性は重いのか？
「毎回インスタンスを作っていたらメモリを浪費するのでは？」という懸念を持つ諸君へ。
HHVMのアーキテクチャを理解していれば、その不安は杞憂だと分かるはずだ。
- JITの恩恵: HHVMは、不変であることが明らかなデータに対して、メモリレイアウトの最適化やインライン化を極限まで進める。
- Copy-on-Writeの最適化: Hackのコレクション操作は内部的に最適化されており、参照カウントとコピーのコストは最小限に抑えられている。
むしろ、可変オブジェクトが引き起こす「予期せぬ副作用」を回避するための複雑な防衛コードを書くコストに比べれば、不変性による設計の単純化は、長期的には圧倒的なパフォーマンス向上をもたらす。
—
チーフアーキテクトからのアドバイス
実務でコードを書く際は、以下のルールを徹底してほしい。
1. デフォルトで `readonly` をつける: クラスのプロパティを定義する際は、まず `readonly` を検討せよ。可変である必要があるのは、ごく一部の「状態保持オブジェクト」だけだ。
2. `private set` ではなく `readonly`: カプセル化のために `private set` を使う古い設計は捨てろ。`readonly` は公開APIとしてもよりクリアな意図を伝える。
3. 型チェッカーを友人に: `readonly` プロパティの誤用を型チェッカーが指摘してくれることは、君の生産性を高める「ペアプログラミングの相方」がいるのと同じだ。
不変性は、コードの「静的安全性」と「推論のしやすさ」を最大化する。Hackという言語のポテンシャルを最大限に引き出し、壊れないシステムを作り上げろ。それが、プロのエンジニアが歩むべき道だ。